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Abstract 


This paper reports the results of research that explores product modeling issues for 
components! that are incorporated in process plant facilities. 


This project begins with an information requirements study that identifies the industry stake 
holders, the business and technical processes involved in component information 
exchange, and the life-cycle information requirements of a typical process plant component, 
the control valve. The findings for the study are described through a review of the 
business issues, and through a process description of the ‘life-cycle’ of a valve within a 
hypothetical project context. Through this case study, the research attempts to identify 
data and engineering knowledge that should be included in a component information model 
to support and improve business process. 


In the final phase of the project, an information model and component selection test case for 
one component type is developed. Based upon the results of the information requirements 
study, the test case explores the integration of an explicit description of product data 
(including form, function, and behavior) and a task based process in a component 
information model. This model provides support for analysis and evaluation of 


component selection in an intelligent engineering application. 


It is proposed that the integration of product and process description in a component 
information model makes it possible to develop information exchange technologies that can 
effectively support and improve business process. This approach is compared to other 
efforts that are being pursued within the research community and industry, e.g., the 
STEP/EXPRESS initiative and related efforts. 


la component is defined as a simple (single part) or complex (assembled part) item that is normally . 
manufactured and sold by a vendor and becomes incorporated into the facility. The term “component 

model” is used to differentiate this information model from “product model” which is used to model the 

facility itself. The terms “part” and “component” are used interchangeably, though we prefer the latter 

because it includes complex assemblies of simple parts. In a process plant, the components consist of 

such items as pipes, valves, pumps, fittings, etc. Clearly, there is a strong overlap in the technologies 

used for modeling components and products, and there are times when this differentiation is not appropriate. 

The business issues for vendors (who sell components) and E/C contractors (who-design and build plants) 

are, however, significantly different. This, and the need to identify the special information modeling issues 

for components, requires that a distinction be drawn between component and product models. 
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Introduction 


Timely and accurate exchange of information about the components that go into process 
plants is an important business problem. Vendor knowledge, contingent upon the quality 
of engineering requirements provided by the customer, often determines final component 
specification for facility design and engineering, and the procedures for component 
installation and maintenance. The specification process for components requires extensive 
information exchange between product vendors, plant designers and engineers. This 
information, in turn, requires considerable effort to access, interpret, validate and transform 
so that the relevant data can be used for project documentation and the necessary 
fabrication, installation, operations and maintenance activities. Failures in the timely and 
accurate delivery of component information causes delays and uncertainty in the 
performance of tasks which, in turn, result in poor component selection, incorrect 
specifications, time delays and re-work, increased change orders, etc. These coordination 
problems increase the transaction costs between component vendors and customers, and 
between the other parties who need the information in the course of the facility life-cycle. 
Thus, improved methods for accessing, storing and using component information can have 


a significant impact on design and construction cost, time and quality. 


The A/E/C industry faces unique organizational and information technology development 
challenges. Whereas businesses in the manufacturing and service sectors focus economic 
organization and deployment of scarce resources towards the design and efficient mass 
production of products and/or services, A/E/C businesses vary organization structure in 
terms of size and the participant mix on a project basis to design and deliver one facility at a 
time. Project organization, facility design and construction processes differ for each 
project according to the type of contract, mix of participants, project requirements, and by 
site constraints. Such constraints highlight the importance of developing effective, 


accurate, and system independent information models for the exchange of product data 


The business problem outlined above is summarized by the following points: 


¢ Component vendor knowledge, contingent upon the customer relationship, often 
determines final component specification, installation and maintenance procedures; 


¢ Considerable non value-added effort is required to access, interpret, validate and 
transform vendor information into project documentation; 


* For the vendor, there is considerable marketing cost to distribute information and 
maintain customer relationships; 


1-] 


¢ On complex projects with many participants (the normal case), the added effort 
increases the transaction costs of data exchange; 


¢ In a fragmented industry such as A/E/C, standardizing the format of information 
content can help to reduce communication and coordination costs; 


¢ Current information products and services do not improve business process nor 
provide added value for information exchange. In particular, they do not add value to 
the owner of the project for use of the facility. 


Objectives 


To understand the problem described above for the process industry, the research studies 
the business issues of component information exchange and the life-cycle information 
requirements for the components that are installed in process plant facilities. A second 
goal of this research has been to prototype a component information model and software 
application that explores the business problem for component selection in an intelligent 
CAD system. 


To ascertain the business problems, the report begins with a review of organizational issues 
in the A/E/C industry that affect communication and coordination amongst project 
participants. Section 1.3 reviews the modes of electronic information exchange, including 
STandard for the Exchange of Product data (STEP), that exist or are proposed to support 
project coordination and communication. Also in this section there is discussion of the 
emerging paradigm of interoperable information exchange that is gaining popularity among 
application developers for the A/E/C industry. 


The review of Standards initiatives includes work in the standardization of parts library data 
that is occurring in the ISO TC184/SC4, the UN EDIFACT, CIAG and elsewhere. 
Several industry consortia in the United States (PlantSTEP, PDXI, CIAG) and 
Internationally (PISTEP, SPI-NL, CAESAR-POSC) are investing considerable resources 
to define STEP for the process industries. These organizations are collaborating to 
develop two STEP Application Protocols; AP 221, process functional representation and 
AP 227, spatial configuration of plant systems. Also third effort, AP 231, that covers 
process engineering data is approved for development. In Part 3, a modeling methods 
analysis places particular focus on understanding AP221 and AP227. In addition, a 
separate ISO standard for parts libraries, ISO 13584, Standard Part Libraries (PLIB) is 
studied2. 


2See Appendix B for a list of organizations. 
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Part 2 investigates the information requirements for components. It describes the results 
of an information requirements study performed with participants involved in the exchange 
of component information for process plants. The investigation focuses on a representative 
test case for one component type, the control valve. The study gathers information from 
the review of product data standards initiatives for the process industries just described, 
and through interviews with representative participants involved in component information 
exchange over the facility life cycle. The findings are described within the context of a 
hypothetical project that describes the ‘life-cycle’ of a valve. 


From the findings for control valves, the key business and technical processes are 
identified that require component information during design, engineering, procurement, 
construction, plant commissioning, operations, and maintenance. The product data and 
engineering process requirements are categorized according to life cycle tasks and a set of 
terms that may be useful for generally describing the requirements for components. The 
findings indicate that a description of component behavior is an important requirement that 
is not currently modeled in the STEP efforts described above. To date, the ISO/STEP 
initiatives for the process industries focus primarily on modeling the requirements for 
facility design and procurement. These standards support only component form 


(geometry) and function characteristics. Component behavior is not currently modeled. 


Also, the research proposes that it is possible to realize added-business value from 
component information models if they integrate a description of component data (properties 
and behavior) and related engineering process. Such an information model can provide 


support for automated component evaluation and analysis software services. 


Part 3 describes a test case that integrates an explicit description of product data and a task 
based process in a component information model. This model demonstrates the partial 
automation of preliminary sizing for a control valve. The implementation uses and extends 
an intelligent design environment called the Semantic Modeling Extension (SME), 
developed by others at CIFE [Clayton, Fischer, Kunz, Fruchter 1995]. Also, in Section 
3.1.4 the report analyzes how the modeling methods for SME, AP 221, AP 227, and PLIB 
satisfy the information requirements that are identified in Part 2. 


The purpose of the test case is to demonstrate the value added benefit of integrating a 
product and process description, and of representing behavior in addition to form and 
function in a component information model. It is contended that information models that 
provide these features are key to the development of software applications which can 
automate sub tasks, increase data reuse, provide design decision support and improve 


business process. 
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Part 1. Background 


1.1 The Process Plant and the Facility Life Cycle 


Process plants are industrial facilities in which material resources are transformed through 

engineering processes into a product, or into a material used in the fabrication of a product. 

Process plants include petro-chemical, energy and power, pulp and paper, sewage 

treatment, and food processing facilities. 

The primary phases of the process plant life-cycle consist of the following; 

¢ Facility Planning: the business plan for the facility and an implementation plan for 
the project; 


e Conceptual Plant Design: the design of the chemical and energy processes used for 
the plant and the approximate layout of the major plant equipment to achieve these 
processes; 


¢ Detail Plant Design: the detailed process design, the detailed engineering design, 
including the electrical, mechanical and piping, structural, and civil engineering 
disciplines; 

¢ Procurement: the procurement of components and equipment that are installed in the 
plant; 


_¢ Construction: The procurement of construction services and-the materials that are 
necessary to construct the facility. This phase also includes the determination of 
delivery schedules, review of specifications for installation and startup, and the delivery 
of plant documentation and warranties of performance; 


e Startup: the steps necessary to start and test the processes in the plant to ensure that all 
portions of the plant operate correctly and at the rated capacities. Training of plant 
operations and maintenance personnel is normally part of this step; 


¢ Operations and Maintenance: the scheduling of maintenance, determination of 
operating behavior, and inquiry regarding availability of replacement components or 
purchase of new equipment. 


In section 2.21 these phases will be described in greater detail. 


1.2 Organizational Issues in the A/E/C Industry 


1.2.1 Factors Affecting Project Organization 


Project organization for the design and construction of process plant facilities varies widely 
according to the economic risks and the participants involved with each project. Some of 
the factors that affect project risk include: 


¢ Project financing: The level of capital investment by the owner and the related lost 
revenue penalties and costs associated with construction errors and/or schedule 
overruns which are born by members of the project team; 
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* Time to Market: Facility owners are increasing the demand for faster project 
delivery. On capital intensive projects, project development time is no longer a 
variable. It becomes a constant that cannot be changed. This factor puts significant 
pressure on engineering and construction professionals to work concurrently and to use 
technology to speed their work without reducing or compromising quality; 


¢ Standardization versus innovation: The degree of design standardization versus 
innovation required by the process. Projects with high innovation often involve 
increased coordination among the project participants. This, in turn, increases the risk 
of design errors that require rework and places increased pressure on project schedules. 


¢ Project complexity and size: On larger projects, the cumulative costs of errors and 
delays can present significant financial risk for the participants; 


* Regulatory bodies: Country, State, and local regulation requirements and permit 
approval processes; 


¢ Labor: Engineering/construction labor availability, costs and quality of work. 


¢ Resource costs: The prevailing costs for construction materials and the products that 
are installed in the facility; 


¢ Client Requirements: The client can specify that particular vendors be used, that a 

given approach to contracts and procurement be followed, etc. 
Generally, the impermanent nature of project work, the high costs of performing it, and the 
fierce competition of open bidding promotes industry fragmentation and specialization of 
design and construction service providers. For projects with less risk, project organization 
will be market driven. For instance, the E/C may sub-contract much of the detailed 
engineering work to low bidders. It is not uncommon for this work to be sub-contracted 
internationally to countries where engineering labor rates are considerably lower than 
domestic rates. As project risk increases, the transaction costs increase in terms of sunk 
resources into coordination efforts and contract governance. In this environment, project 
organization tends to become more centralized. For example, the E/C would perform all 
design and engineering services in-house. Joint ventures provide another organizational 
form that distributes project risk. 


The variance in project organization models helps to explain why IT systems in A/E/C 
organizations have developed into "islands of automation", and subsequently, why product 
information exchange is problematic. As a result, current modes of exchange fail to 
capture all the information that is required to satisfy the life-cycle requirements of facility 


owners and operators. 


1.3 Information Exchange in the A/E/C Industry 


This section provides an overview of the information exchange problem in the A/E/C 
industry. It summarizes the business problems and challenges that affect information 


exchange in project based organizations, and it discusses the modes of electronic 
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information exchange that support project coordination and communication. The two 
primary extant modes of electronic exchange are file exchange (IGES, .DXF, STEP) and 
electronic transaction (EDI). In addition, this section discusses the emerging paradigm of 


interoperable information sharing. 


The interoperable application paradigm is gaining popularity amongst applications 
developers and professionals within A/E/C. This section highlights the Industry Alliance 
for Interoperability (IAI) that is working to develop this paradigm, and summarizes the 


nature of its work. 


1.3.1 The Current Exchange Model 


Figure 1-1 depicts the predominant model for project information exchange. Participants 


in the facility life-cycle develop 


information using in-house software ere 
P : ptructural 
systems that often are incompatible c 5 | iy 
= 
4) 


a 
aa \ Sy —_ 


between disciplines. Frequently, hard 
copy constitutes the media of 
exchange. Such materials are static 
and not computer processable. 
Electronic information exchange is 
Static also since there is no automated 
coordination (active change notification 


between contingent design elements 


and/or version management). In 
addition, electronic exchange often Figure 1-1. Node to Node Information 
requires translation, which increases PRM: 
the risk of information loss between systems. The potential errors in node to node 
exchange is a problem of N(N - 1) complexity. The current model does little to improve 
support for the iterative, change oriented nature of design and engineering practice; nor 
does it reduce the redundant generation of design knowledge from project to project. This 


model is low on the scale of the automation steps described below. 
1.3.2 Levels of Automation 


Figure 1-2 originates from a study on personal computer use performed by [Nolan, Norton 
& Co. 1987]. It describes four levels of automation and indicates its value added for 
business. 


hs 


ae 


IV. Automation of Business & 
Infrastructure Investment 


Strategic Business 


Vision (10X Return) 
III. Automation of processes 


and Technology clustering 


II. Automation of tasks Tactical Business 
and individual learning Vision (3X Return) 


I. Technology 


Proficiency Technology Driven 


Vision (10-20% Return) 


— 


Figurel-2. Managing Personal Computers in the Large Organization, 
Nolan, Norton & Co. 


Organization Learning 


The study advocates a monitored, incremental approach towards business automation to 
control risk. Nonetheless, the graph shows clearly that significant returns on technology 
investment occur at levels III and IV when organizations successfully automate work 
processes that cross functional and organizational boundaries. The current electronic 
information exchange model primarily supports level II automation. We shall see from the 
information requirements study that the status of component information exchange is 
consistent with this level of automation. Yet component information exchange involves 
the cross functional and inter-organizational communication where the greatest gains can be 


achieved. 


1.3.3 Construction Component Information Services 


To assess the status of electronic component information services, two providers, 
Autodesk®, Inc. and Information Handling Services® (IHS) were interviewed. In 
addition, the World Wide Web (WWW) was searched for on-line services. The following 
table highlight the benefits and drawbacks of these services: 


The features of these services confirm that component information exchange products do 
not yet support improved business processes. The WWW search did show that 


component information is coming on-line. At this junction however, the available 


haan, 
~~ 
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Information Source | Benefits / Drawbacks 


CD ROM 
IHS 18,000 mfrs. / 63,000 catalogs. Most are scanned images. 


No Structured Data except for electronic parts 

Searchable by Keyword 
Improves search time, but no value added for computer-based 
user work processes (IHS is working on ways to integrate their 
product data into work processes) 
Outdated information usage paradigm (bit maps of paper 
information cannot be understood by the computer) 

Autodesk 

ME parts search able by component attributes 
.DWG format drawings available with component ID and 
specification attributes 
Value added limited to graphics and some product data 


Parametric generation of CAD drawings in future version 
OO St Oe SU I eS net Peay Yet __ s at on-line, but think market is not read 
‘On-Line si 


roe Info. Structured documents, text, (os Mogetytitcigeggss 
Center Coverag Be; currentl vey low, but chang ging | fast 
information 


Others Interactivity; Medium. Users can control search, but can not do 
much with the acquired information 
(Oe | Visibility; Low, Web sites can be difficulttofind ==  —si 


Li aay 


Se Interoperable objects with behaviors FSFE TE classes 
Catalogs supported by industry and/or ISO standards) 
/ Libraries with... 


Table 1-1. Construction Component Information Services 


information does not integrate with end user systems or provide design decision support. 
With the phenomenal rate of WWW development and the advent of technologies that enable 
distributed, platform independent computing (e.g. Java), improved information services 


will be forthcoming. 


1.3.4 Business Concerns 
Information Issues 


The interviews conducted during the information requirements study also identified the 
business issues for the participants involved in component information exchange. The 
following table relates the issues to participants; 


ans 
~~ 


3 See the WWW home page for this project, URL: www-leland.stanford.edu/~jaa/ressum.html 
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Business / Information Information Engineer/ Facility 
Issues Vendor Integrator Contractor Owner 


Component DataStandards |  $[| © | 


OCC OL VM tals, ., ae sCen tent | SUNS ARNO gl staal? createiliois akira | 
Data Longevity isis Ss amelie | gaa bos ratelsiews Xsowiad zatraXuod _| 
plies touViarket Seeee en en ee A xX 
Pe OSOMMclKChiip eee meee pee ee | 
Kinproved! Mamtenancesaaais t| gamer Ameen | Mme BRRENE NOT | AF ee suN [ORLIW Xie | 
facility life-cycle 


Table 1-2. Business Information Issues 


All parties perceive the benefits and costs of standardization. The responses are consistent 
with contingency theory that standardization of business language reduces communication 
ambiguity, decreases the need for redundant communication, and increases information 
processing capacity [Galbraith 1977]. Similarly, all parties recognize the business value of 
information security. There is less consistency amongst the participants with respect to the 
remaining issues. It is worth noting that all the issues are relevant to the facility owner 


who ultimately drives the information requirements. 
The Business Barriers 


The business barriers to effective component information exchange include: 
e Industry Fragmentation 
e No Standards for data exchange 


¢ Long term benefits of detailed information modeling conflict with modeling cost and 
short term business goals 


¢ Differing levels of automation; 
— Low automation for some processes/companies 
— Many companies are not on-line 
— Lack of interoperability 

¢ Belief that competitive advantage lies in proprietary knowledge; 
— Engineer/Contractor: technical expertise and cost estimation knowledge 
— Vendor: technical marketing 

¢ CAD systems do not meet user requirements os, 


¢ Organizational inertia; 
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— Embedded culture resistant to change 
— Risk aversion 
— Lack of understanding and training in new business processes 


— Cost of converting to new business procedures and standards 


While the business challenges are formidable, technologies that automate inter- 
organizational information exchange between vendors and users of components can 
provide significant benefits. New methods for communicating and using product 
information will affect project team structure and relationships with product vendors. The 
boundaries between customer and supplier may change as emerging technologies 
encourage new work processes. The use of electronic networks, e.g., Internet, could 
allow widespread access to product data and knowledge. As an example, it may become 
advantageous for engineering professionals to allow product manufacturers access to 
conceptual design models of facilities. Conversely, product manufacturers would allow 
design professionals instant access to their product information and fabrication data so that 
they may accurately estimate costs and delivery schedules. In this capacity, engineering 
professionals and product manufacturers will collaborate as team members to effectively 


achieve project goals for design, cost, quality, and schedule. 


The following section describes the current modes of electronic information exchange and 


presents the basic concepts of the interoperability paradigm that is gaining popularity. 


1.3.5 Modes of Electronic Information Exchange: file exchange and 
transaction processing 


Drawing file exchange between design and engineering CAD systems is limited primarily to 
product geometry. Figure 1-3 shows the communication model between heterogeneous 
CAD systems. The primary CAD file exchange formats are; 


Figure 1-3: Communication between 
Heterogeneous CAD Systems 


Initial Graphics Exchange Format (IGES) 


IGES is an ANSI standard for the exchange of geometry and graphics data. The semantics 
are limited to geometric entities (lines, arcs, circles, etc.). Therefore, it is not capable of 


explicitly representing higher level objects such as components (doors, windows, control 
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valves). As a result, usage problems stem from its semantic limitations. For example, 
‘semantic overloading’ can occur when the same graphic entity represents two or more 
ideas. 


Drawing Exchange Format (DXF) 


DXF is a defacto standard published by Autodesk. It has gained widespread acceptance 
because of Autodesk’s dominant position in the CAD marketplace. Like IGES, it is 
limited to geometry and graphics entities only. Also it shares the same semantic 
limitations. 


AutoCAD Drawing (DWG) 


In North America, Autodesk’s penetration into the A/E/C CAD marketplace is so prevalent 
that DWG files are the predominant format for file exchange between parties who have 
AutoCAD. DWG files are smaller than DXF. For an AutoCAD only solution, all the 
information in the drawing can be retained during exchange. Some AutoCAD competitors 
have even added the ability to read and write DWG files. Nonetheless, DWG exchange 
has pitfalls as well. Since AutoCAD is highly customizable, it is very difficult to enforce 
guidelines or standards for drawing organization (layer names, line weights, font styles, 
block names, etc.). Thus, although DWG exchange is successful, the receiver often 
spends considerable time converting the drawing organization to an internal set of 


standards. 
STEP 


Recognizing the limitations of IGES, the ISO launched STEP in 1984 to replace it . 
Formally, STEP is described as; 


“*..a neutral mechanism capable of completely representing product data 
throughout the life cycle of a product...The completeness of this 
representation makes it suitable not only for neutral file exchange, but also 
as a basis for implementing and sharing databases and archiving.” 


[PDL eg 1992) 


Informally, STEP is a methodology and set of technologies for industry professionals to 
agree upon what to call things and how to describe them in an unambiguous, neutral and 


computer sensible format. 


A STEP standard is defined by one or more application protocols (AP). An AP defines 
and scopes a specific industry need, documents the information requirements, provides a 
map from them to an EXPRESS [ISO IS 10303-11 1994] information model, and specifies 
software application conformance requirements for the standard. A Suite of APs normally 
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comprise an industry standard. AP 221 and AP 227 are the first two STEP standards for 
the process industry. For a list of APs related to A/E/C, See Appendix E. Figure 1-4 
shows the relationship between the primary documents that constitute an AP and a STEP 


conformant software application. Describes eae eo Satisfies Data 
* Application Activity Model (AAM). | Processfor “| (gcone) 


The AAM describes the processes for an 
industrial application. It is normally 
created using the Icam DEFinition 
method (IDEFO) [ICAM 1981] and is a 
tool for developing and validating the; 


e Application Reference Model (ARM); an 
object model that defines the data, 


Satisfies Data Suppos pe 


(ARM) 


Requirements of 


relations and constraints of semantic Application 
elements. It is normally created in Inter fae aaeretc. 
NIAM or IDEF1x [NIJ 1989]. Model (AIM) 
¢ Application Interpreted Model (AIM); an é Algorithmically 
EXPRESS model developed from the based on 
ARM and the STEP Integrated 
STEP 
5 
Resources>. Contormant 
There is an explicit mapping between every sete te 
ARM object and its AIM counterpart. The Figure 1-4. OMT* AP object 
relationships 


definition of the AIM from the Integrated 
Resources constitutes the basis for integration amongst a suite of APs. 


Benefits and Drawbacks 


STEP is a rational methodology for defining and agreeing upon nomenclature and 
semantics for domain objects, processes and resources. It provides a computer sensible, 
non-ambiguous and implementation independent representation of product data. To date, 
the scope of STEP standards within A/E/C are limited to descriptions of product geometry, 
function, and to some degree procurement requirements and product description change 
control. These features have the potential to improve communication through the exchange 
of product data semantics beyond product geometry. 


STEP enjoys strong support in the aerospace, aeronautics, mechanical, electronic and 


automotive industries. In A/E/C, the process industry is developing STEP to enable data 


40bject Modeling Technique [Rumbaugh, Blaha, Premerlani, Eddy, Lorensen 1991] 


SThe Integrated Resources are domain independent EXPRESS schemas that may be referenced by an AP. 
The stage at which the they are brought into an AP is called Integration. This tsa process during which 
STEP/EXPRESS experts analyze the ARM and apply the STEP Integrated Resources where possible. 
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exchange for all phases of the facility life cycle. STEP for architecture and construction 
lags these efforts. However work on information models for structural, HVAC, explicit 


shape representation and a construction core model is ongoing. 


STEP follows an incremental development methodology and the design of STEP 
information models can support information sharing. However, STEP implementation 
tools primarily support static file exchange. The technology was initially designed for data 
integration, not data interoperation. It lacks support for concurrent design activities such 
as active change notification or automated constraint management. STEP file exchange 
does not guarantee against information loss. If two systems have a different conformance 
class approval, translation from the higher to the lower conformance class system will 
entail information loss. Last, STEP lacks support for object behavior, the formalization of 
design knowledge and object performance that is necessary for automated decision support 
and improved business process. 


Transactions 


Electronic Data Interchange (EDI) is a set of protocols for automating common business 
transactions. EDI is comprised of standard data forms, called Transaction Sets. Some 
examples follow; 


Transaction | Description Transaction | Description 
Set No Set No. 


832 ~—ss| Price/Sales Catalog [810s Imvoice 

De aed Lae ree 
Notice/Manifest 

| nme dmalc|l PCT Zc) = 2c al KGa a 

Request 

8 


$10 

$62 
Purchase Order 
Acknowledgment 


Table 1-3. Transaction Sets 
Along with Electronic Funds Transfer (ETF), transaction sets expedite the flow of 


ioe) 


information and funds necessary for the sale and procurement of products. Product 
information for EDI consists of product identifiers (catalog IDs) for inventory and control 
during a transaction. Transaction sets can explicitly model product data, however to do so 


requires customization between an individual supplier and purchaser. 


To implement EDI two companies must agree to modify their.existing procurement systems 
to acommon format. Thus the motivation to comply is only as strong as the demand by a 
company’s customers. Within A/E/C, EDI currently is limited to procurement of bulk 
items in large organizations. Nonetheless, at some point product model data may link to 
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transaction set information to integrate the formal product description into procurement 


practice. 


1.3.6 Interoperable Information Sharing 


Object oriented software technology shows promise for providing the project coordination 
and design decision support features that are not yet available using file exchange 
technology. Several software vendors and A/E/C practitioners are working to move 
information models from geometry-based documents (or files) to design models comprised 
of real world objects. The ‘interoperable information sharing’ paradigm hopes to: 


e Integrate object models by including in the object definition the geometry, relevant 
design and engineering knowledge, and industry-specific information. 


e Support the life cycle information requirements. 


e Share the project model between multiple software applications; Instead of file 
exchange, software applications will be able to access information directly from the 
objects that comprise the design model. 


e Provide multiple views of the object data for various engineering and design tasks. 


e Enable a dynamic project model. Constraint relations between persistent, integrated 
objects will make active coordination and control possible. 


Integrated Object Models 


Integrated objects will incorporate a ae 
description of form, function and oad map ngineer 


behavior. These terms are developed 
in depth in Part 2 (see forward). 
Building Shared Project HVAC 


Extending current STEP models that Bana Engineer 
primarily describe form and function 
to a representation that includes object 
behavior, will enable automated design Control 

Mgr. ngineer 
evaluation for a set of functional 


requirements 4 Behavior Industry Foundation Classes 
(c) 1995 - Autodesk Inc. 


representations in information models 


Figure 1-5. Interoperable Information 
will be a key feature for extending Sharing 


their business value by integrating 


them with design and engineering tasks and business process. 
Shared Objects 


Sharable objects will support integration by allowing different software applications to 
access and use project data. To achieve integration, it will be necessary to understand and 
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model the object content that satisfies the facility life cycle requirements. Published, 
standard programming interfaces to these models will be necessary as well so that software 
applications can add, delete and modify information. This is necessary for the 


representation of accumulated knowledge throughout the facility life cycle . 
Dynamic Project Model 


Automating coordination activities will be as important as information sharing. Explicit 
representation of relations and dependencies between design elements will support 


coordination goals. Consider moving a door. The position of the electrical outlet is 


dependent upon the position of the door. 


Normally, the change is handled manually. The 
Design 


architect moves the door symbol and the electrical 
Change 


engineer moves the outlet symbol. When 

communication involves a static model, an 

additional exchange is required. A dynamic Figure 1-6. Design Change 
information model would automate this dependency and, ideally, provide active notification 


for the change to the interested parties. 


1.3.7 Approaches to Interoperable Applications 


Established in 1995, the Industry Alliance for Interoperability develops the Industry 
Foundation Classes (IFC) [IFC 1995]. The IFC are libraries of object classes that are 
commonly useful to an Industry. It is the hoped that they provide a “mechanism for object 
sharing, which (equals) interoperability across the boundaries of software applications” 
[IFC 1995]. The IAI enjoys growing industry support. Autodesk, which initiated IFC 
before spinning it off to the IAI, and Bentley Systems are members, as are several value 
added developers for AutoCAD and MicroStation. Over forty companies from several 
disciplines participate in the IAI and outreach to STEP, the Construction Specifications 
Industry (CSI), and several overseas organizations in Europe, Singapore and Japan is in 
progress. The IAI faces complex modeling challenges. Success depends upon the 
cooperative participation of all organizations. The key development concepts include; 


Object Classification 


This involves the development of a common nomenclature and semantics for real world 
design objects by teams of industry representatives and then published for industry. While 
the initial focus is on objects that encapsulate form and function, the ultimate goal is to 
include object behaviors that enable design evaluation. Success-for IFC requires the 


involvement of industry and software vendors to specialize the core model. The IAI can 
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benefit substantially from the A/E/C modeling foundation laid down within STEP, and 
extend it to support object behavior. Autodesk is developing IFC conformant products, as 
is Bentley Systems using Objective MicroStation technology. Further challenges that face 
the IAT include: 


¢ Understanding the life cycle information requirements of industry domains (including 
the business issues and processes using this data); 


¢ Understanding how behavior will be supported; 
e Investigate technologies to extend and specialize core objects, and to link Mfr. data); 


¢ Assure public object definition so that applications can access information from others 
that a user may not own; 


¢ Develop standards for use and extension of class libraries with sharable interface to 
LES. ; 


e Assure data integrity when transferring data models that are dependent upon libraries 
from one computer to another; 


e Provide application compatibility across CAD platforms; 
e Retain compatibility with legacy data and systems (if this can be done); 


¢ Provide a mechanism to update class definitions as they become more mature over time. 


1.4 Summary 


Part 1 of this report describes the role of information exchange technology in the A/E/C 
industry. It is argued that distributed computing technologies (e.g. the Internet) and object 
oriented product modeling technologies may enable the A/E/C industry to overcome some 
of the problems associated with communication and coordination of information about 
components. For these technologies to have a positive impact, it is necessary that they be 
motivated by a strategic business vision in which the technology is used to automate task 
performance and change business process. To do this, it is necessary to understand the 
life cycle information requirements for the tasks and processes that involve components and 
to encapsulate the necessary design knowledge and object behavior in the object model. 
Models that explicitly represent such information are key to the development of software 
applications that can provide design decision support for task assistance and/or automation. 


Part 2 reports the results of a study that investigates the life cycle information requirements 
for one component type, the control valve. 


Part 2. Life Cycle of a Component 


This case study describes a project scenario that identifies the product information for 
control valves that is needed during the various processes of the facility life cycle. The 
process descriptions that follow are important because they give insight into the information 
modeling requirements. These requirements can be modeled using various modeling 
methods. Part 3 of this report describes an implementation of a component model for 
control valves that satisfies a subset of the requirements identified below. It then is 


contrasted with other modeling approaches in light of these requirements. 


2.1 Methodology for the Study 


The study was conducted through interviews that were conducted with industry 
professionals who take part in component information exchange, and through ongoing 
dialogue and email exchange with individuals involved in the development of product 
modeling standards for the process plant industries. The primary participants involved in 


part information exchange for the A/E/C industry are shown in the diagram below; 


Product = 
Product 
fe woeiticsaiy a Information 
i as é Delivery 


Strategy 


(eee A 


Beery 
Designer/Engineer 


= Product 
_| Modeling 
LS Strategy 


Figure 2-1. Users and Providers of Construction Information 


2.1.1 Facility Life-cycle Coverage 


The interviews were conducted with thirty-eight individuals representing 12 companies. 
They were conducted on an informal basis, guided by a question list developed for each 
company type. The intent of the interviews was to gain an overall picture of the 
relationship between business process and information development for the components 
that are installed in process plants. The interview questions included inquiries about tasks 
that the participants perform, the information they require, the views-of the data that they 
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have, how they use it, what media they use to exchange the information, and what 
software tools are used to process it. The responses were recorded in note form during 
each interview. The types of companies included in the interviews included; 

e 3 engineering/construction firms that perform process plant work; 

e 2+ valve manufacturer/vendors (2 manufacturers, 1 vendor/distributor); 

e 2 product information providers; 

¢ 3 Facility owners; 

e 1 EDI Vendor. 


See Appendix A for a list of the companies involved in the study. 


In addition, information was gathered through a survey of current industry initiatives to 
create standards for the exchange of product information. See Appendix B for a 


description of these initiatives. 


2.1.2 Analysis method 
The IDEFO process modeling method [ICAM 1981] describes the processes. This 


diagramming methodology provides a process decomposition technique that characterizes 


processes and functions in terms of inputs, constraints, outputs and mechanisms. 


Control 


Function 


Mechansim 
Figure 2-2. An IDEFO Box 


Within the IDEFO framework, the top level diagram shows the entire process plant life- 
cycle in terms of six major processes. This diagram derives from the Integrated Building 
Process Model developed by [Sanvido, et al. 1994] and from the process model diagrams 
in the draft standard [ISO CD 10303-227 1995], Plant Spatial Configuration. The project 
scenario description decomposes five processes, Facility Design, Procurement, 
Construction, Commissioning and Maintenance to a level of detail where it is possible to 
identify the information characteristics necessary for valve sizing, selection, procurement, 
installation, commissioning and maintenance. This exercise identifies the processes, 
constraints, participants (in terms of mechanisms), and views of the data (in terms of inputs 


and outputs) that each participant has relative to part information exchange for valves. In 
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Section 2.4 the information requirements that are derived from this process description are 
categorized according to component properties, behaviors, task coordination dependencies 
and administration attributes. 


2.1.3 Purpose 


The case study describes a project scenario which identifies the product information in a 
broad sense (data, knowledge, behavior) that should be represented for valve components. 
This information should satisfy the requirements of the individuals who use the information 


during the various phases of the process plant life-cycle. 


2.2 Case Study Project Description 


Hypothetical Refinery Project Organization for 
Design and Construction 


Project Owner _(Petrochemical_ Company) 


Facility “>is Bodies” 
Operation § § 2 


== Ee 
. VendorA 


Procurement F 
Department 


Electrical 
Contractor 


Figure 2-3. Hypothetical Refinery Project Participants 


Based on the information acquired through the interviews, a Hypothetical Refinery Project 
(HRP) was created. The plant under design will be owned by a major petro-chemical 
company. Its purpose is to process crude oil into various fuels such as gasoline, jet and 
diesel fuels and as other petro-chemical products such as many types of lubrication oil. 
The plant is built on water-font land owned by the project owner. Figure 2-3 describes the 
top-level organizational structure that manages activities in the facility life cycle. The entire 


project is financed by a credit line provided from a bank to the project owner. 


The bank hires a consulting engineering firm to evaluate the economic and technical 
feasibility of the owner’s plan for this project. The owner signs a contract with a large 
engineering firm that performs design and manages construction of the facility. During the 
design stage, the general engineering firm subcontracts the detailed design to specialty 
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engineering firms in each discipline. The actual construction activities are performed by a 
general and sub contractors. However, the design engineering firm manages material 
procurement and coordinates the subcontractor's work. Upon completion of construction, 


the facility is handed to the owner for operation. 
2.2.1 Functional Process Model 


An IDEFO process model for the HRP, see below, identifies the information requirements 
for each activity during the facility life cycle. The following section identifies the key stake 
holders in each phase of the process plant life-cycle. Section 2.3 analyzes the detailed 
activities in the design, procurement, construction and maintenance phases to identify the 


information requirements of each stake holder for valves. 
Life-cycle of a Process Plant 


Figure 2-4. IDEFO node AO (see forward) describes the entire facility life-cycle of the 
HRP. It consists of six phases; Plan Plant Project, Design Plant, Procure Components, 
Construct Plant, Commission Plant, and Operate and Maintain Plant. A brief description 


of the parties involved in each phase follows. 


Plan Plant Project (Figure 2-4. IDEFO, node Al) 


According to the business needs and general philosophy for the project, this phase defines 
the scope of the project and identifies the overall requirements for the facility to be built. 
The outputs of this phase include basic documents for the project such as a financial plan, a 
project execution plan, and the design scope. 


The key stake holders in this phase include the management, facility planning team, process 
design and engineering team of the owner, the financial houses, bonding and local 


government agencies. 
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Design Plant (Figure 2-4. IDEFO, node A2 


Based on the plans and the design basis produced in the planning phase, the design phase 
produces construction documentation for the facility. The facility is specified in detail, and 
the required components and equipment are identified. In section 2.3.1 the design phase is 
decomposed into four traditional sub-processes; conceptual and detailed process design, 
and conceptual and detailed engineering. The Design team performs the conceptual 
process design and solicits information about materials and components from vendors and 
suppliers to determine the process details of the plant. This phase produces an 
approximate plant design and the estimated cost and time based on the business 
requirements identified during the planning step. Once the schematic design is set, it 
proceeds into the detailed design phase. The detailed design team consists of the design 
and engineering function in the owner’s organization and the design division of the selected 


prime contractor. 


The prime contractor subcontracts the detailed engineering activities to specialized 
engineering firms. Various regulatory bodies provide constraints and guidelines for the 
design of the facility through standards, regulations and design codes. The output of this 


phase is a set of detailed plans, specifications, and a schedule. 
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Procure Components (Figure 2-4. IDEFO, node A3) 


The procurement of components and equipment constitute a significant part of process plant 
projects. Normally at least 60% of the cost of the plant is represented by the material and 
equipment used for the plant. In this phase, the owner and/or prime contractor selects 
vendors and procures the components and equipment for the planned facility. The key 
stake holders in this phase include vendors, the facility owner, and the prime contractor's 


design, procurement and construction management team. 


Construct Plant (Figure 2-4. IDEFO, node A4) 


According to the design and the specifications, the procured items are assembled and 
installed during the construction phase. The output of this phase is the erected facility and 
post construction documents that contain the information necessary to maintain and operate 
the facility. 


Stake holders in the construction team include the construction management team, the 
procurement department of the prime contractor, the specialized subcontractors, the 
component vendors and the material suppliers. The owner’s construction management 
team includes the facility planning function, and the design / engineering functions. This 
team provides overall control and management services to monitor the prime contractor. 
Construction activities are regulated by the safety and construction codes provided by 


regulatory bodies. 


Commission and turnover Plant (Figure 2-4. IDEFO, node A5) 


During this phase the construction contractor must prove the operation of all plant systems 
defined by the detailed design specifications and reconcile any differences between the 
specifications and as-built conditions. Commissioning normally proceeds in stages from 
tests using inert materials to the use of the production stream. Upon satisfactory process 
unit testing, the plant owner accepts the facility for operation. 


Operate and Maintain Plant (Figure 2-4. IDEFO, node A6) 


The completed plant ready for operation is turned over to the owner’s facility operation 
team. While running the facility the operation team provides necessary maintenance and 
retrofit services through vendors and contractors on a periodic basis and as needs arise. 
The operation of the facility is regulated by corporate requirements, standards and 
regulatory codes. 
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2.3 Information requirements for Valves 


From the overall description of the facility life-cycle, the requirements study focuses on a 
functional description of control valve sizing, material selection, procurement, installation 
and maintenance. The goal is to identify the objects, object properties, stake holders, and 
processes that are necessary to characterize the requirements for a valve component 


information model. 


Valves are devices that control the flow of a stream in a process system by introducing and 
modulating pressure drop within the valve body [Chevron corp. 1993]. The function of 
a valve is either to block flow or to control it by means of a throttling mechanism. The 
conditions under which a valve performs this function varies with the process under 
consideration, the environment in which it is placed, and the service requirements. The 
definition of the process, the system that supports it, and subsequently the specification of 
the equipment that meet the system requirements for process control, occurs within the 
phase labeled Design Plant (IDEFO, node A2) on Figure 2-4. 


2.3.1 Description of the Valve Sizing and Selection Processes 


Figure 2-5. IDEFO, node A2 represents the detailed activity decomposition for the design 
phase. 
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The design phase separates into four sub-processes; conceptual process design, conceptual 
engineering design, detailed process design, and detailed engineering design (IDEFO A2.1- 
A.2.4) On a real project, one or more of these phases may be combined or compressed due 
to time to market constraints. For the purposes of the study, the four traditional sub- 
phases remain to articulate the work flow and the information needs and uses that are 


necessary to size and select valves. 


The following discussion about sizing and selecting a valve is drawn from [ISA-S75.01 
1991], [Chevron corp. 1993], and [ISA 1976]. 


Definition of Stream and System Data 


During conceptual process design (IDEFO A2.1), the prime contractor's process 
engineering group develops the technical definition for the overall plant requirements and 
identifies candidate processes that fulfill them. The outputs of conceptual process design 
include [PISTEP 1994]: 

e the required unit operations for the plant; 

e the process stream properties and composition; 

e energy/mass balance equations for the system; 

¢ the control philosophy; : 


¢ process flow diagrams which document the process definition, the stream definition, 
and the control philosophy; 


¢ acost, benefits and timings analysis; 
e the safety and regulatory requirements. 


The need for control equipment, such as a valve, may be indicated at this stage, but the 
specifics of how control is achieved and the equipment configuration that will enable 
control is not articulated until the following stage, detailed process design. Nonetheless, 
the stream data and the process definition developed in this phase provide the system 
requirements for sizing and selecting valves. For a given valve, this information consists 
of the stream data below. 


Stream Information 


¢ Chemical composition e Temperature 

ey hase e Specific gravity 

¢ Fluid pressure in pipe e Min. steady state controlled flow rate 

e Vapor pressure e Max. steady state controlled flow rate 

e Density e Max. flow rate to recover from a flow disturbance 
e Viscosity 


2-8 


Information Media 


The media used to record the design information include the Process Flow diagrams in 
CAD format, process specifications (text documents), and a preliminary engineering 
equipment and project management database. The level of integration between these 
documents varies. Most engineering firms maintain links between a project equipment 
database and the CAD drawings. However, there may not be electronic integration with 
project management and procurement systems. 


Participants in Exchange 


The participants in the conceptual process design phase include the process engineer of the 
E/C firm, and the design/engineering and project management representatives from the 
owner team. These participants normally exchange the information in hard copy format. 


This form of exchange is typical of inter-organizational information exchange. 
Valve Sizing 


Valve sizing occurs in the detailed process design phase. Figure 2-6. IDEFO, node 
A2.3.X describes valve sizing. 
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Figure 2-6. IDEFO node A2.3.X, Do Preliminary Sizing! 
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1The dots in the IDEFO diagram indicate bi-directional information flow. 
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In this phase the specifics of the piping system are designed and the piping system 
equipment is identified and sized. In addition to the stream data, the pipe information that 


is necessary for sizing a valve includes: 


° Valve inlet and outlet nominal pipe diameter and swages is applicable; 

° Applicable design code (ASME); 

° Piping specifications (schedule, class and flange rating) for compatibility of design; 
° Environmental constraints in the form of electrical hazards, climate, atmospheric 


contamination, and plant procedures (wash down and decontamination). 


Sizing Process 


The process of sizing a valve involves understanding the valve's role as an energy 
consumer in a thermodynamic system. A valve functions by "consuming" the pressure of 
a stream passing through the valve body. 


Usually an energy provider, such as a centrifugal pump, induces a stream to flow in a pipe 
by introducing pressure into the system. The pressure in the pipe is a function of the flow 
rate of the stream, the head to be overcome and losses due to friction. The pressure drop 
caused by friction losses increases with the square of the increase in flow rate. 


Transverse Section through Pipe 


Inlet 
Pressure 


Pump Discharge Pressure 
Stream Vena Contracta 
Control Valve 


Pressure Drop 
Allowance 


Hydraulic Friction 


Pressure (PSI) 
Velocity (FPS) 


Losses 


ee Outlet Pressure 


rg Liquid Vapor 
Pressure 
Flow Rate (GPM) 
Valve Velocity Pressure Profile 


Source: Chevron Corp. 
Figure 2-7. Characteristics of Control Valve Function 


A valve should be sized to consume "whatever pressure drop is available to maintain a 
system at a set point" [Chevron corp. 1993]. Looking at the diagram above, one 
observes that at high flows, a valve does not have to consume as much pressure to control 
the flow. This diagram demonstrates that it is necessary for a valve to operate across a 


range of operating flow conditions. To determine the correct valve size, the process 


~~ 
~~ 
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engineer determines the required pressure drop capacity of the piping system for minimal, 
maximal and upset condition flows”. Then the engineer selects a valve with the right 
service characteristics and capacity factor that matches the requirements across the specified 
range. Normally, a valve will be sized to achieve effective control over a range from the 
minimum flow -5% to -10%, to the maximum flow +5% to +10%. This range is called 


the "rangeability" of the valve. 


Engineering Considerations 


Because the valve causes a pressure drop in the system for a given stream velocity, one 
must calculate whether the pressure drop will fall below the vapor pressure of the stream 
for its operating range of temperatures and pressures. If this occurs, cavitation or flashing 
may occur. Cavitation is a condition where the stream changes state from liquid to vapor 
in the valve (see Figure 2-7 above). When the system pressure recovers after exiting the 
valve body, the stream’s vapor bubbles collapse, causing cavitation. If the valve outlet 
pressure stays below the stream vapor pressure, flashing will occur. Either of these 


conditions will cause noise, vibration and ultimately damage to the valve and pipe. 


The capacity index of a valve for a given set of stream conditions is called the coefficient of 
flow, or Cy. There are standard calculations for determining the Cy for a valve dependent 
upon the type of flow (laminar, turbulent, or transition), the inlet and outlet pressures, the 
flow rate, the specific gravity of the stream, and upon any differences between the piping 
geometry and the valve body inlet and outlet diameter [ISA-S75.01 1991]. 


Process Summary for Control Valve Sizing 


To summarize the valve sizing process, the process engineer accounts for a range of 
performance properties of the valve that are dependent upon the thermodynamic 
characteristics of the process stream and upon the piping system geometry. Thus the 
information that is necessary to support valve sizing should include the valve form 
(geometry and size), the valve function, and knowledge which describes valve behavior 


based on a range of functional conditions, or states, of the process fluid and pipe system. 
Information Sources 


When the process engineer performs the initial valve sizing, he/she may consult a part 
database maintained by the procurement department to obtain information about which 
valve to select. Alternatively, he/she may consult an in-house library of manufacturer's 


2An upset condition is a disturbance that causes one or more operating parameters to fall outside of its 
design range. 


product literature. In addition, most valve manufacturer's and many database system 
vendors (e.g. Oracle) provide software applications that automate valve sizing and selection 
and link the results into the engineering management database system. Currently, these 
applications are not yet integrated into the CAD systems in which the engineering teams 


develop the process design and detailed engineering documents?. 
Information Media 


When preliminary sizing is performed, a rough specification for each valve is developed 
and entered into an equipment list program linked to an engineering management database. 
In addition, the process and instrumentation diagram (P&ID) is developed during detailed 
process design and some valve information is indicated on these drawings. At this point 
each valve is given a unique project identification code that is referenced on the drawings. 
If further valve information is available at this stage, it is shared with: 


¢ Mechanical engineering/piping: valve envelope dimensions and required clearances for 
maintenance. 


e Structural engineering: valve weights, center of mass, mounting styles and positions. 
e Civil Engineering: valve weights, center of mass. 


e Electrical engineering: electrical ports and hookup requirements. 


Participants in Exchange 


Once the capacity of the valve is sized correctly for a piping system and stream, the process 
engineer hands the valve material specification to the control systems engineer who 
develops a complete specification for the valve with respect to its required service 
condition. In the HRP scenario, this hand-off would involve exchange of the piping 
system functional information through hard copy drawings and database reports, or by 
translation of the electronic data from the process design data management system to 
independent systems maintained by each of the detailed engineering sub contractors. 
Electronic translation of this information carries the data exchange risks described in Part 1. 


The process plant STEP development efforts (see Part 3) are addressing this issue. 
Valve Material Selection 


Valve material selection occurs during the detailed engineering phase. Figure 2-8. IDEFO 
node A2.4.X details valve material selection. 


3The difference between these software applications and model based behavioratreasoning is explored in 
Part 3. 
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Figure 2-8. IDEFO node A2.4.X, Valve Material Selection 


Valve material specification includes the determination of: 


Valve body; Id (Tag), nominal diameter, ANSI class, material, end connection type, 
no. ports, Travel direction to open, flow direction 


Trim; Id, cage material, bushing material, seat ring material, valve plug (material, 
guiding type, balance type), port size, opening characteristic (see trim discussion 
below), shutoff class 


Bonnet; style, boss size, packing (see packing discussion below), bolting, bonnet, 
packing Flange 


Actuator; size, style, air to actuator, valve action on air failure, hand jack position 
Positioner; type, input signal, accessories, valve action on signal increase 


Transducer; input signal, output signal, action, mounting, airset, certification, 
explosion-proof approval, intrinsically safe approval 


L/P Positioner; certification, explosion-proof approval, intrinsically safe approval 


Several of these items depend upon the service requirements for the valve. The 


thermodynamic portion of the system requirements have been discussed above. 


The valve material should satisfy the requirements of the process fluid for resistance to 
corrosion and erosion. Normally, the valve body material will match that of the process 


pipe material. 
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The selection of trim is critical for establishing the type of control the valve shall provide. 
Trim are the materials within the valve (the plug, seat and cage) that come into contact with 
the process fluid and provide the control function based upon the change in position (travel) 
of the trim within the valve. Valve travel ranges from fully open to fully closed. There 
are three primary trim characteristics for control valves [Chevron corp. 1993]: 


¢ Quick opening trim is used primarily for on-off service. It enables a maximum change 
in flow rate at low valve travel. 


e Linear opening trim provides control where the flow rate change is directly proportional 
to the valve travel. 


¢ Equal percent trim provides control where equal increments of valve travel produce 
equal percentage change of flow. 


The diagram on the left below shows the ideal, or inherent, flow characteristics that result 
from each type of trim; 
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Figure 2-9. Ideal versus Actual Control Valve Performance 


In reality, friction losses in the system due to rust accumulation produce different behaviors 
once the valve has been installed and the system is up and running nine months or more. 
The diagram on the right shows the installed characteristics. With time, equal percent trim 
behaves more like linear trim. Linear trim, in turn, behaves more like quick opening trim. 
Depending upon the "burn in" time for the system and the relative cost of different trim 
characteristics, it may be advantageous to select equal percent trim for a service condition 
which requires linear flow control. The change in flow control performance due to trim 
deterioration demonstrates that the information requirements for selecting materials include 
the representation of the changes in the material's behavior across time as well as inherent 
behaviors when first installed. 
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There are further considerations for selecting valve trim that are not be discussed in this 
paper. What is important to note however, is that the rationale for material selection is 
based upon design criteria that, in turn, are predicated upon assumptions concerning the 
required service conditions and upon applicable business rules (environmental standards, 
etc.). This point is also valid for the other materials listed above. As an example, a brief 
discussion concerning the factors that affect the selection of the valve packing material 
follows. 


Air Quality Regulations 
Composition 
Temperature 


Pressure 


Control Systems Engineer 


Figure 2-10. Specify Packing 


Valve packing prevents leakage of process fluid past the surface of the valve stem or shaft. 
In addition to the fluid composition, and the operating temperature and pressure, the 
material construction of the valve stem should be considered when specifying the packing 
material [Chevron corp. 1993]. The selection of packing material is particularly 
important with respect to federal regulations for fugitive emissions imposed by the Clean 
Air Act of 1990. The specification of packing materials for valves in petro chemical 
applications are largely driven by these regulations. This example demonstrates another 
example of how government regulations affect the design assumptions required for a set of 


service conditions. 


Material Selection Summary 


These examples demonstrate how an information model, to effectively provide design 
decision support, should be capable of explicitly representing assumptions about service 
conditions, the applicable business rules, and also, how changes in these factors over time 


affect design criteria. 


This discussion of the parts which comprise a valve also make it evident that an information 
model, to effectively support the maintenance and operations life-cycle phases, should 


explicitly represent a component's constituent parts. Section 2.3.5 discusses some of the 
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typical problems affecting contro] valve component parts and the information requirements 


that should be satisfied for the maintenance phase. 
Information Sources 


When selecting valve materials, the control systems engineer consults vendor product 
catalogs and often contacts a vendor sales representative directly for decision support. In 
most circumstances, the information exchange occurs via hard copy. In some companies, 
vendors are beginning to provide this data in electronic format however, as described 


previously, no product data exchange standards exist yet to facilitate exchange. 


Information Media and Exchange 


The control systems engineer records the valve specification onto a data sheet and also may 
enter the information into the engineering management database. Valve class sheets for a 
project are generated from the database. This system will normally be linked to an 
integrated project management system that tracks procurement and field management 
functions. While these database management systems enable the information to be shared 
within the prime contractor organization, it should be remembered that exchanging it with 
sub-contractors requires translation to separate systems for each participant. The specified 


valve information is shared with each of the engineering sub-contractors: 


° Mechanical engineering/piping: detailed valve dimensions and required clearances 
for maintenance. 

° Structural engineering: final valve weights, center of mass, mounting styles and 
positions. 

° Civil Engineering: valve weights, center of mass. 

° Electrical engineering: electrical ports, hookup requirements, and safety 


requirements for electrical zones. 


After valve selection is complete, the procurement department uses the information to 
expedite the procurement process. The following section describes the procurement 
phase. 


2.3.2 Process Description for Valve Procurement 


Figure 2-11. IDEFO node A3 depicts the procurement phase of the facility life-cycle that 
relates to control valves. With respect to valve information requirements, the emphasis in 
the procurement phase is the exchange of technical data between the engineering firm and 
the valve vendor to successfully negotiate and transact a purchase agreement. Ideally, no 


new process data or project planning information is required during this phase. 
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Figure 2-11. IDEF0, node A3, Procurement Process 


Nonetheless, both the engineering firm and the vendors allocate resources to validate the 
information they receive from one another. In addition, it shall be shown that the 
specification for the valves used in the project often changes as a result of vendor review of 
project documents. The validation effort by both parties and the re-specification of valves 
by the vendor represent non-value added or redundant effort. Historically, this double 
work is due to the open bidding process and design responsibility liability for the design 
engineering firm. The entire procurement cycle for valves can consume from eight to 
twelve weeks of project time. Some firms are correcting this problem by instituting new 
procurement procedures, in the form of vendor alliance agreements, to eliminate the non- 
value added effort. Such agreements have been shown to reduce valve selection and 
procurement costs by half. These agreements redesign the procurement cycle by shifting 
responsibility for valve specification and selection onto the vendor. However, some firms 
have not yet entered into vendor alliance agreements. In addition, these work process 
changes have not yet carried over to interoperable exchange of electronic design documents 
and interoperable IT systems. Such automation has the potential to effectively place the 


vendor knowledge on the desktop of the design engineering firm. 


Within the traditional procurement phase five sub processes are identified. They are 


beg 


briefly described below: 8 
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Maintain Vendor List (Figure 2-11. IDEF0, node A3.1) 


The E/C firm's procurement division maintains a list of vendors with which the company 
does business. One aspect of maintaining this list is to keep an updated database of vendor 


pre-qualifications, product offerings, product availability, technical data sheets, and prices. 


On many projects the facility owner specifies an approved valve vendor to assure consistent 
standards for plant equipment. In this case, the E/C works directly with the vendor to 
specify the valves for the project and forgoes the traditional bid process. 


Procure Bid Packages and Solicit Bids (Figure 2-11. IDEF0, node A3.2) 


When no vendor is mandated by the facility owner, the procurement department assembles 
the valve specifications (data sheets), the project specifications, the process flow diagrams 
and process and instrumentation diagrams (PFD and P&ID), the project schedule, and the 
regulatory, test and contractual requirements into a Request for Bid package. The bid 


package is the information exchange media used to solicit bids from qualified vendors. 
Review Requirements (Figure 2-11. IDEF0, node A3.3) 


After the vendor receives the bid package, it thoroughly reviews the valve data sheets and 
develops a bid based upon the information provided. Currently, most of the data exchange 
between the engineering firm and the vendor is accomplished using hard copy. Some 
valve manufacturers are developing systems that facilitate electronic exchange of the 
technical data for order entry, and they provide some product information back to the prime 
contractor in electronic format. However, once again, there are no published standards 
available yet to guide the development of these systems. 


Evaluate Bids and Negotiate Purchase (Figure 2-11. IDEF0, node A3.4) 


After the vendor submits a bid, the prime contractor reviews it. The procurement 
department receives the bid from the vendor and passes it to the design team consisting of 
the engineering firm's control system engineer and construction management personnel, 
and the owner's technical representatives. After reviewing the bids, the team selects a 
vendor. 


Modify Valve Specifications (Figure 2-11. IDEF0, node A3.5) 


Finally, after a vendor is selected, the interested parties finalize the order entry. Since the 
vendor specializes in knowledge about the product, it often recommends changes to the 
valve specifications. This can be an iterative process between the engineering firm and the 
vendor. alt 
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Analysis of the Procurement Process 


Within the traditional procurement process one observes that valve specification may occur 
up to three times; during plant design, during the RFP vendor revue, and last, when all the 
parties agree to the final order entry. Alliance agreements effectively redesign the 
procurement process to reduce much of the redundancy. These agreements are driven by 
the fact that often vendor knowledge, dependent upon the quality of the documents 


provided by the engineering firm, ultimately determines component specification. 


A life-cycle information model for components that can represent technical project data, 
component behaviors, design criteria and the business rules that determine product 
selection, may ultimately enable the encapsulation of vendor knowledge into information 
objects. One day, such objects may be capable of reducing errors, compressing 
component procurement time, and automating product specification on the engineer's 


desktop. 
2.3.3 Construction Phase 


IDEFO Diagram node A4 represents the process model during the construction phase. 
Through the five activities shown in the diagram, the plans and specifications produced in 
the design phase are translated into a built facility. Throughout construction, the 
participating parties require different views of the information for valves that have been 
outlined thus far. In addition, the information requirements for valves extend from data 
about their inherent properties, to data that is necessary to facilitate purchase, transport 
product, support installation, and monitor progress at the construction work face. The 
focus turns from product description and specification to governance of the terms of 


exchange, installation procedures, and progress measure. 


The following section focuses on two activities within the construction phase, the delivery 
and installation of valves. The following functional descriptions identify the exchange 


participants and their information viewpoints. 
Deliver Valve (Figure 2-12. IDEFO node A4.2) 


The delivery of valves consists of a sequence of activities starting with order placement by 
the prime contractor's procurement team. According to the data sheets, the vendor 
fabricates the valves, and ships them to the site by contracting with an independent 
shipping company. When the valves arrive at the site, the construction team inspects 
them. Then they are stored in an on-site inventory until they are installed. 


aria 
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Figure 2-12. IDEFO node A4, Valve Installation Process 


The information required for this activity includes the detailed construction schedule, the 
valve data sheets and the purchase price. Upon placing an order, the procurement 
department stipulates a delivery date from the vendor and sends the information along with 
the order form to the construction team. This is normally done by entering the data into an 
integrated project management system that tracks equipment transactions. Therefore the 
order data are stored electronically in the prime contractor's procurement system and the 
procurement information is accessible for the construction team. Between the procurement 
department and valve vendor, however, the information is exchanged by mail and fax. 


The media are hard copy documents. 


The information on the order form is then entered into the vendor's inventory control 
system which handles the manufacture and shipment of the valve components. The 
vendor requires the ID numbers of the valves along with the name, type and specification 
for each valve. During manufacture, the prime contractor may review vendor progress, 
and generate progress reports to assist the design and field activities. The prime contractor 
also issues stage payments based upon vendor progress toward fulfilling the order. The 


prime contractor schedules the valve shipments. 


Before shipment, the valves are tested for casting defects by the vendor periodically in the 
presence of the prime contractor. The results of the tests are documiented and attached to 
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the shipment manifest. These quality verification documents also contain information 
about the physical properties of the valve materials. The valves that pass the quality tests 
are released for shipment by the prime contractor and furnished to a shipping company for 
delivery. A shipping list serves as an order form for shipment. The above information is 
exchanged by conventional information systems such as mail, telephone and fax. All the 
information is in the form of text documents. 


The delivery of the valves are handled by the independent shipping company. Its primary 
information interests are the weight of each valve and the size of the packing boxes. The 


form of information and method of its exchange is the same as described above. 


Upon arrival of the shipment, the prime contractor conducts an inspection to assure that the 
order form, shipment form and the valves match. The valves are then stored and 
maintained in an on-site inventory that is tracked by an integrated project management 


database controlled by the prime contractor until they are installed. 


Delivery Process Summary 


At this stage the information requirements for representing valves change from data that 
describe the design of an engineered artifact, to data useful for monitoring the status of a 
physical object. The information requirements for the Delivery process emphasize data for 
controlling production, monitoring quality and assuring compliance with the project 
schedule. These information requirements are normal for manufacturing processes and are 
well understood. In fact, EDI standards already exist that formalize and automate these 


procedures. 


It is worth noting that EDI transactions for non bulk items have not yet penetrated the 
construction product procurement processes for the A/E/C industries. This is probably 
due to the fact that the standards are still relatively new and they are designed primarily for 
transactions of commodity, not engineered items. In time, EDI transaction sets may 
contain pointers to product information models based on STEP (or other) standards that 
provide the necessary detail to enable electronic transactions for complex, engineered 


products. 
Install Valve (Figure 2-12. IDEFO node A4.3) 


The valve stored in the on-site inventory is eventually installed by the construction team 
according to the construction schedule. Valve installation occurs in the following 


sequence. 


aa 
~~ 
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Structural erection: The structural contractor erects the support structure for the piping 
system. This includes the construction of concrete members, structural stee] members, 
brackets, and tie rods that support the pipes and valves. The structural contractor is 
interested in the dimensions and specification of the structure, the physical support 
mechanisms for the valves, and their positions. The information is provided primarily in 
structural drawings and is exchanged by hand and informal communication. Typically, the 
structural contractor is not interested in the properties of a valve. However, he often must 
refer to the mechanical and electrical drawings when the information on the structural 
drawings is not sufficient. The information media and exchange methods are the same as 
describe above. In addition, the contractor sometimes refers to scaled 3D models to 
resolve spatial coordination ambiguities between the structural members and the mechanical 


piping and components. 


Mechanical Installation: The mechanical contractor is responsible for the installation of 
valves along with the piping and HVAC system. His information requirements for valves 
include the valve specifications (class sheets, drawings and diagrams), their size and 
weight, and type of connection. The information is provided in a set of specification 
documents and mechanical drawings, and is exchanged by hand and informal 
communication with other parties. The activities are also controlled by the construction 
plan for valve installation. The construction schedule is provided by the construction 
management team in document format as well as informally through job meetings. As 
with structural erection, the mechanical contractor may also obtain vital information 
concerning spatial coordination by examining a 3D scale model if the detail design engineer 
develops one for the project. 


Electrical Installation: After completion of structural and mechanical work, the installed 
valves are handed to the electrical contractor for wiring. Electric installation requires 
information about the required electrical voltages to operate the valve components, and 
safety requirements for special electrical zones. The information is provided with the valve 
specifications and is on the electrical drawings. The method of information exchange is 
the same as that described for the other installation activities. 


Inspection: Upon completion of each of the activities described above, the construction 
management team inspects each contractor's work. The inspection involves examination 
of the work for conformance to the specifications. For this, the construction management 
team needs all the information identified above for the three stages of valve installation. In 


addition, the methods and criteria for the inspections are furnished in an inspection plan, 
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government codes, and regulations. The information media and the exchange methods are 
the same as described previously. 


Installation Process Summary 


In this phase the information requirements involve reference to design data generated 
previously and to construction management information for coordination requirements 
between the disciplines. The specialization of the construction trades is reflected in the 
data views which require only the information that is necessary to perform a specific task. 
This point illustrates another requirement for a component information model. It should be 
capable of furnishing multiple views of the knowledge and information it contains. These 
views should be organized according to the requirements of users. In turn, the 
construction trades pass information regarding work face progress back to construction 


management so that it may monitor progress. 
2.3.4 Commission Plant 


The purpose of this phase is to prove the operation of the plant as defined by the 
construction documentation and project specifications by introducing process materials into 
the plant and operating it under test conditions. Concerning control valves, there are five 


primary activities that occur prior to plant handover; 
Perform Trip Tests 


Conduct safety tests that force trip conditions. These tests evaluate the loop between 


control instrumentation and valve actuator response for upset conditions. 
Perform Cold Commissioning 

Cold commissioning tests the process unit circuits using inert feed stock materials. 
Perform Hot Commissioning 


This activity performs operational tests using production feedstock materials. Hot 
commissioning verifies that the process transformation of feedstock to product proceeds as 


designed. 
Tune Control Systems 

Process circuit tuning occurs during the commissioning tests. 
Perform Acceptance Testing 


Finally, plant testing occurs under operating conditions. During this activity, operators 


establish benchmark performance characteristics for the plant under varying production 
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conditions. At this time it is possible to establish benchmark performance measures for the 


installed equipment, including control valves. 


At the conclusion of acceptance testing, the facility is turned over to the owner. At this 
time the prime contractor furnishes the as-built drawings, operating procedures and 
manuals, and the acceptance test results. The turnover process is formalized by the 


acceptance of a turnover certificate by the owner. 


2.3.5 Operations and Maintenance Phase 


This section summarizes the maintenance information requirements for control valves. 
The discussion of maintenance issues is drawn from the interviews and from _ several 
articles on control valve maintenance [Fitzgerald 1990], [Maintenance Technology 1992], 


[Emerson 1990] provided by Fisher Controls. 


Upon completion of construction and plant commission, the facility owner takes control of 
the plant for operation. Plant operators attempt to optimize process efficiency while 
minimizing risk and plant down time. Plant maintenance becomes a strategic factor that 
affects the bottom line. While valves are relatively simple and rugged compared to other 
process control equipment, they play an essential role in the plant control system and their 


maintenance is critical to plant operation. 
Performance Requirements 


The maintenance criteria for valves differ with the process in question. In a petro chemical 
facility such as the HRP control valve overhaul occurs on a rotating schedule every three to 
four years for a process unit. During an overhaul, a process unit is taken off-line and all 
the valves are disassembled and rebuilt. Typically a process unit will have from 100 to 
150 control valves and the service cost per valve is roughly $3,000.00 (line removal, 
disassembly and inspection, re-assemble and replacement on the line). This activity for 
one process unit costs from $300,000.00 to $350,000.00 for valves alone. Multiply this 
cost times the number of process units in the plant and the that valve maintenance costs can 
become significant depending upon the frequency of the disassembly cycle. This example 
represents just the out of pocket cost for valve maintenance. There are four primary 
performance requirements concerning valve maintenance: 


¢ Process efficiency: process yield, quality and energy consumption are the measures. 
Control loop variability can result in control valve response that is inaccurate or jerky. 
These effects can cause the quantity and purity of the process to be sub-optimal, which 
results in production inefficiency. 


¢ Process reliability: This factor affects plant down time, which is critical. It is estimated 
that “...each year, control valve problems alone cost the averagé nuclear power plant 
$2-3 million in lost revenue” [Emerson 1990]; 


2-24 


To reduce downtime, plant designers introduce design redundancy such as block and 
bypass valves around each control valve. While effective for maintaining production, 
these systems increase plant design, construction and maintenance costs; 


Fluid containment: There are two types of problem, internal and external leakage. 
Internal leakage results in reduced process control, lost product, and process 
composition variability. External leakage also results in lost product. Perhaps more 
important, it can result in fugitive emissions that endanger workers, surrounding 
communities and the environment; 


Maintenance costs: The plant operator seeks to optimize process efficiency while 
minimizing maintenance costs. It is necessary to maximize the value of dollars spent to 
increase the return on the maintenance investment. 


Typical Problems 


Positioner/Control Loop variability: Friction from corrosion of the plating surfaces on 
the stem can cause sticking and jerky operation. Alternatively, excessive friction can 
be caused by tight stem packing. When this occurs the valve operator builds up high 
pressures to force a control change. Instead of continuous control, the positioner 
jumps. The valve tends to operate in jerks. Often, it jumps past the intended set point 
and the controller continues to operate, trying to correct the position. When this 
occurs, variability as a percent of span goes up and the process does not stay at a set 
point; 

Improper seating: A poorly adjusted actuator can cause plug seating problems. There 
are two primary sources of sub-optimal actuator performance; Air leakage from a 
pneumatic actuator and actuator spring fatigue. A small air leak can increase response 
time, while a large leak can prevent the valve from opening or closing fully. A poorly 
adjusted spring can also prevent the valve from achieving a full stroke. 


Some typical maintenance problems are due to disruptions in the quality assurance feedback 


loop between the customer and valve vendor, and/or a lack of control over the materials 


used for maintenance and repair. These problems originate from two sources; 


Plant operators use local, on site, or nearby off-site repair vendors instead of the 
original supplier for maintenance activities. When the owner/operator uses its own 
shop, the original supplier does not get accurate maintenance data that may be used to 
improve product; 


Plant maintenance engineers use 3rd party replica parts. While perhaps less expensive, 
such parts may be low quality. Such materials skew the maintenance data. Material 
traceability is lost and it becomes impossible to track where the part was acquired, who 
acquired it, what the failure rate is, etc. 


Maintenance programs 


Facility operators have three maintenance program options; 


Reactive 


Some facility operators wait until there is a problem before performing valve maintenance. 


The reactive maintenance strategy addresses the major problems. Unfortunately however, 


minor problems that affect production efficiency can go unnoticed. 
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Preventive 


The preventive maintenance strategy is the most common. The HRP maintenance scenario 
presented above typifies this approach. While preventive maintenance reduces risk, it 
often involves unnecessary work that increases maintenance expense. During a petro 
chemical process unit overhaul such as the one described above, typically only one quarter 


to one third of the valves actually require disassembly. 
Predictive 


There is technology that enables operators to monitor control valves on a regular basis and 
predict their useful service life by comparing current data with historical performance data. 
This procedure, called signature analysis [Fitzgerald 1990], does not require valve 
disassembly and is gaining performance evaluation sophistication. It can augment a 
preventive maintenance program by helping to prevent unscheduled down time and by 
identifying sub-optimal valve performance before visible problems occur. The valve 
signature method “measures valve stem travel in response to the instrument signal while 
simultaneously measuring instrument air to the positioner, supply pressure and actuator 
pressure.’ [Fitzgerald 1990] From these measures, any two of the following parameters can 
be analyzed and compared to an optimal case [Fitzgerald 1990): 

¢ Actuator spring rate and bench set; 

¢ Valve stroke and friction; 

¢ Stroking speed; 

e Seat load; 

e Stem-nut adjustment; 

¢ Air supply pressure; 

e Positioner calibration, linearity and hysteresis; 

e J/P calibration linearity and hysteresis; 

e Packing friction. 


Summary of Maintenance Issues 


The requirements discussion shows that maintenance activities are tightly linked to business 
objectives for product production. An information model that explicitly represents the 
constituent parts and accessories of a control valve can contribute to preventive maintenance 
and the development of predictive maintenance capability. Explicit representation of the 
constituent parts should support these views of control valve parts: 


Part identification and property description 
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This information includes a unique part and supplier identification, the material description, 


test approvals and the part properties that characterize geometry, material and function. 


Part functional behavior and_performance evaluation logic 


This information includes the engineering knowledge necessary to derive part behavior. In 
addition, to support predictive maintenance goals, the information model should be able to 
represent the benchmark evaluation knowledge that is derived from the functional data. 
This would entail encapsulating “signature analysis” functionality within the information 
model. 


Maintenance management information 


The model should support maintenance management goals by tracking time-based data of 
the pertinent information described above and maintenance operations. Such data includes 
a history of valve signature indicators, who performs maintenance, the valves that are 
overhauled, the materials/parts that are changed, etc. This information makes it possible to 
evaluate the efficacy of maintenance strategies and decisions concerning the purchase of 


replacement parts. 


An information model that is capable of providing these services can be used effectively in 


a program to re-engineer the business process for maintenance activities. 


2.4 Analysis of Information Requirements 


The level of analysis for the requirements can range from the determination of data types 
for computer sensible representation, to the necessary business models for electronic inter- 
organization information sharing. While each level of analysis is important, the conceptual 
emphasis of this case study is the identification of component information that the project 


participant wants to communicate with others. 


Project participants want to describe components, understand how they perform and use 
this information for various activities across the facility life cycle. Users also need to 
manage procurement transactions involving components. For this they need to record and 
monitor the who, what, when, where, how and why of a transaction. Furthermore, users 
want to know process information concerning components that assists in the coordination 


of activities. 


2.4.1 Component _ description 


Appendix C contains a matrix that lists 150 life cycle information requirements for control 


valves grouped amongst 15 major tasks. For reference, figuré 2-13 (see forward) 
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The matrix divides the information requirements vertically by life cycle phase and task. 


Columns four through nine categorize the user requirements that are described informally 


above. Formal definitions for each category follow: 


Properties 


Assigned: A characteristic of a component that is measured or observed. The 
nominal diameter of a control valve is an assigned property. The assigned 
properties of a component do not change; 


Design Requirement: A characteristic of a design context that is independent of a 
component but applies a design intent to it. Design requirements can and do 
change. The required outlet pressure of a fully open control valve is a design 
requirement; 


Design Standard: Similar to a design requirement, however a design standard does 
not normally change. Corporate design standards, government regulations or 
requirements pertaining to specific design criteria represent design standards. 


Behaviors 


Computed: a value derived from reasoning about a component. The form of 
reasoning may vary (e.g. heuristic, analytical, stochastic). The Instrument 
Society of America (ISA) coefficient of flow formulas enable the derivation of a 
value that indicates the flow capacity of a control valve for a given set of functional 
conditions. Behaviors that derive from the application of design requirements to 
the model of a given structure or form for a component may also be called predicted 
behaviors; 


Measured: a value that is recorded from observation or measurement of actual 
component performance. Control valve diagnostics are measured behaviors. 
Time may also be a characteristic of measured behavior. For instance, control 
valve signature measurements are analyzed at time intervals. Such behaviors may 
be called actual behaviors. 


Administration 


Information that supports the flow (coordination and control) of information and resources 


for transactions (procurement, etc.). Formalization of transaction information currently 
falls within the EDI and ETF domain described in Part 1 and is largely beyond the scope of 


this report. For convenience, transaction information is grouped within Administration. 


However, there is project and material identification information associated with 


components that does not describe properties of them. Such identifiers (project numbers 


or material handling serial numbers) are grouped within Administration. 


2.4.2 Task Coordination 


The IDEFO diagrams show the primary activities and flow of information related to control 


valves throughout the facility life cycle. Three types of task coordination requirement are 


implicit in these diagrams: ce 
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Design Contingency 


The information interdependence between project elements. For example, the detailed 
specification for a control valve depends upon the stream definition. [Eastman 1995] 
shows it is possible to define contingency constraints between design elements and assign 
constraint violation functions for them that monitor and control] design change within the 


product model. 
Change Notification 


Given a design change, this term characterizes the act of notifying the appropriate project 
participants. There is ongoing research in the development of design process support tools 
that enable active notification [Khedro, Genesereth, Teicholz 1993], [Eastman 1995] for 


product model changes. 
Task responsibility 

The assignment of ownership and accountability for tasks. 
Other Factors 


Time contingency and resource availability are additional critical factors in the determination 
of coordination requirements. They are not represented by the IDEFO diagram technique. 
Time contingency is normally indicated on Critical Path Method (CPM) schedules. 
Resource availability is also monitored using CPM or other tools such as GANTT charts. 


A component model that references vendor manufacturing information could provide input 
to a project process model for some of the coordination requirements listed above. 
Specifically vendor data for manufacturing schedules and product availability would be 
valuable. In addition, component models could contain software hooks for the 
establishment of design contingency and change notification relations with other objects 


once the component is referenced in a product model. 


2.4.3 Purpose of Categorization 


Categorizing the information requirements fulfills two goals: | 


e Generalization; factoring the specific requirements for control valves into a superset of 
information types assists in generalization the findings; 


e Evaluation; these categories are useful criteria for evaluation of different modeling 
methods. In Part 3, several modeling methods will be described and compared with 
respect to the criteria. 


Te 
~_— 
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2.4.4 Task Based Views 


In the matrix, partition of the requirements by task suggests one of many possible views of 
the information. No individual project participant needs or uses all the information that is 
listed. Most participants work with a subset that is relevant to the task at hand. 


From the decision support perspective, a component model should be capable of 
representing multiple views of underlying information for various work requirements. 
The work requirements vary depending upon the purposes for use and the time at which it 
is required or available. Similarly, the product model in which the component is 
referenced should also be capable of representing these views and of providing a design 
context for the characteristics of the component model that are functionally dependent on 
the design. 


Some argue that support for engineering reasoning and decision support should be 
provided within software applications that access and manipulate an underlying information 
model. It is a research issue whether it is possible to develop a domain independent 
conceptual framework that supports view based knowledge and reasoning for engineering 


Processes. 


2.4.5 Tools and Media for Documentation and Exchange 


It is clear that paper is still the primary documentation for most existing and many new 
facilities. Paper based information exchange is particularly prevalent for inter-organization 
information exchange. In a programmatic sense this information is informal. It is not 
represented explicitly and is not therefore computer sensible. Part 1 already addresses the 
problems associated with static information and the potential solutions for the 
representation of product information such as STEP. Nonetheless, many other forms of 
information developed for projects fall outside the current limits of STEP models. This is 
true particularly for documentation of project specifications and design standards. 
Information models for components will need to accommodate informal, text based 
knowledge representations along with explicit, computer sensible product information for 


some time to come’. 


4Commercial technologies that enable the development of this information in symbolic format remain far 
on the horizon. Nonetheless, some promising technologies were encountered during the study. At CIFE 
[Howie, Kunz, Binford, Chen, Law 1995] report technology that enables the conversion of paper P&ID 
drawings to CAD graphics and an underlying, STEP compatable symbolic model of the process circuits, 
equipment and instrumentation. Within the NSF/ARPA/NASA digital library project [Phelps, Wilensky 
1995] report the development of extended optical character recognition (OCR) technology that creates 
structured text in HTML format (complete with hyperlinks to related database information) directly from 
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2.5 Challenges 


The detailed requirements identified in the case study represent the union of what was 
learned through the interviews, interaction with experts working on STEP information 
models, and a literature search. Despite these efforts that resulted in the identification of 
150 separate information items, the enumeration of the requirements is assuredly 
incomplete. For example, most of the information is collected from E/C firms, 
information integrators, facility owners, and valve vendor representatives who participate 
in technical marketing. The information requirements study does not include detailed 
requirements from the perspective of the component the manufacturer for component 


production and test procedures. 


It has already been noted that each participant involved in information exchange about 
components has a specific perspective or view of the requirements dependent upon many 
factors, including the usage requirements and time at which the information is needed. 
Furthermore, no one participant has all the knowledge and expertise to develop a complete 
model. These factors point to the need for an information model that supports design 
schema evolution and enables the dynamic addition of information throughout the facility 
life cycle. This point has been expounded by [Eastman 1995]. One should not lose sight 
of the relationship between such capabilities and their importance for supporting business 
process. To achieve business goals, individuals and organizations access, manipulate, and 
transform information for a business purpose. This often results in new, derived 
information about a product. This study shows, to some degree, the broad range of 
information requirements for one component across the facility life cycle. Nonetheless, 
the findings of the study are informal. To validate them, it would be necessary to conduct 
similar studies that identify even more requirements, etc. An information model that has a 
general mechanism for schema evolution can support a complete representation of 
engineering design objects and their interrelationships [Phan, Howard 1993] without 
attempting, a priori, to fix and define a domain for which the information requirements 
inevitably change. 


scanned text images. Technologies such as these have exciting potential for-svercoming the current 
information media barriers to electronic information sharing. 
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2.6 Case Study Conclusion 


The life cycle information requirements for control valves begin with component design 
and specification. In procurement and construction the emphasis changes to identification 
of available products that match the design specifications, governance of the terms of 
exchange, installation procedures, and progress measure. From the plant commission 
phase through operations and maintenance, the focus becomes measurement and evaluation 
of component performance against production benchmark values and subsequent 


maintenance procedures. 


With requirements that serve such diverse purposes, component information models should 
support multiple, task related views of the underlying information. Furthermore, an 
interface between the component and product model is required so that characteristics of the 


component that are functionally dependent upon a design context can be specified. 


The case study focuses particularly on the information requirements for users to describe 
components, understand how they perform and use this information in various activities 
across the facility life cycle. The following information categories result from the 


requirements identified for control valves: 


Component Description 
* component properties . 


* component behaviors 


Task Coordination 

e Design Contingency 
e Change Notification 
e Task Responsibility 
e Time Contingency 


¢ Resource Availability 


Administration 
e Material identification 


¢ Transaction processing 


It is possible to improve the integration of component/product representation for 
design/construction process models by including an explicit representation of behavior and 
process related information. The incorporation of engineering knowledge and behavior in 
component models makes it possible to provide decision support for various engineering 
tasks, such as component selection and specification. The incorpération of enterprise 
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manufacturing data related to components makes it possible to provide input to project 


coordination and control activities. 


Part 3 presents a test case. It is a component information model for one component type, 
the control valve. The primary purpose of this model is to explore the modeling issues 
concerning the inclusion of a behavioral representation that provides decision support for 
the valve sizing and selection task. The information criteria from the case study are used to 
compare the modeling approach used for the test case with other modeling methods studied 


during the research project. 


es 
~_—s~ 
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Part 3. Test Case 


Introduction 


Part 2 identifies several engineering processes that relate to control valves during the facility 
life cycle. To support these processes, the study describes the information requirements 
for a control valve information model and relates them to more general requirement 
categories. These categories include component properties, behaviors, task coordination 


dependencies and administration attributes. 


Some of the processes are engineering tasks that require the application of engineering 
knowledge and reasoning to compute a performance property for a control valve. This 
reasoning is representative of design and engineering knowledge work, and particularly of 
tasks that involve analysis and evaluation of designed elements. Such knowledge 
translates project requirements and constraints into the designed product model. 
Automation of knowledge work is common in many software applications (e.g., finite 
element analysis programs). However, information models developed for standard 
product data exchange do not yet explicitly support this important task related dimension of 
design and engineering. 

Modeling behavior in addition to the functional and structural properties of components 
makes it possible to provide analysis and evaluation software services for component 


selection and usage. These software services should formally describe and integrate a 


description of component data and related engineering process. In so doing, they would 
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offer value-added functionality for customers through the improvement and automation of 
existing process. Product, process information model integration can result in increased 
reuse of data, better component selection, improved decisions for operations and 


maintenance, and improved coordination between project participants. 


Part 3 explores this concept through development of a test case that integrates an explicit 
description of product data and a task based process. The test case is an information 
model for a component and a piping sub-system. It includes a behavioral representation 
that supports one engineering task, preliminary valve sizing and selection. It uses the 
Symbolic Modeling Extension (SME) [Clayton, Kunz, Fischer, Teicholz 1994] modeling 
methodology that builds upon Form, Function, Behavior (FFB) [Kunz 1988], [Clayton, 
Fischer, Kunz, Fruchter 1995] concepts to model the control valve component and its 
placement in a piping sub-system of a P&ID product model. This model provides support 


for analysis and evaluation of component selection in an intelligent engineering application. 


Current efforts to create standard information models satisfy some of the requirements 
identified by the study and highlighted by the test case. Other requirements remain out of 
scope for current efforts. Section 3.1 describes the test case information model, two 
process industry STEP APs (EPISTLE Core Model/AP 221 and AP 227), and ISO 13584 
Part Libraries (PLIB). It analyses how these approaches satisfy the requirements. In 


Section 3.3 the test case implementation is described. 


3.1 Comparative Modeling Methods 


3.1.1 Preliminary Note 


Elucidating the differences and similarities between FFB/SME and the other approaches 
assists in a better understanding of each, and hopefully demonstrates how FFB concepts 
can contribute to established modeling efforts. While the information requirement criteria 
from Part 2 apply to each modeling method, it is important to place each one in a relative 
context with respect to its scope and purpose. 


Each modeling method focuses on a set of functionality that serves different purposes. 
STEP serves current industry practice by enabling the exchange of product data in a 
neutral, implementation independent, standard format. PLIB provides a component and 
component library representation structure for a similar exchange function between 
component suppliers and designers/procurers. 


In contrast, the SME is a research prototype that is scoped to address a specific aspect of an 
information modeling problem. To date, SME demonstrates the integration of product and 
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process models to provide intelligent decision support tools for the analysis phase of 
designing (see forward). Whereas STEP supports current work process, the goal of SME 
is to change work process by attempting to increase decision power through increased 
modeling power [Koskela 1995]. Yet, SME has limited scope. It is by no means a 
complete solution nor is it subject to the rigors and problems of scale and validation 


encountered in commercial implementation. 


In addition, it is also important to frame the information requirements satisfied by STEP 
within the constraints of an incremental development strategy. As stated in section 1.3.5, 
STEP standards develop as a suite of information models (Application Protocols) 
categorized by domain. This strategy enables a life-cycle model to emerge as APs are 
approved to the international standard. Information that is lacking currently in a suite may 
be added eventually in a new application protocol. In addition, there are ongoing 
improvements to the expressiveness of the STEP information modeling language, 
EXPRESS [ISO IS 10303-11 1994]. Thus the modeling power and content development 
of STEP is a moving target. The incremental development strategy is correct given the size 
and complexity of the modeling challenges. In addition, industry needs and interests 


justifiably prioritize AP development. 


Nonetheless, an incremental development strategy that satisfies distinctly different 
requirements can make it challenging to achieve unified, consistent results in a timely 
manner. The challenge becomes more complex within an organization composed of 
several groups trying to satisfy different industry sectors. The speed with which STEP 
delivers useful solutions to industry problems is a key factor for its acceptance. Given the 
complexity of the mission and the constraints on resources required to achieve success, it is 
vitally important that STEP identify and address the areas in which it can provide the 
biggest benefit for industry. While behavior and engineering process representations with 
STEP models would increase the complexity of STEP modeling and validation efforts, 
hopefully this report indicates that such functionality can provide significant new benefits. 


3.1.2 Modeling Method Description and Analysis 


Table 3-1 below summarizes how well the modeling approaches satisfy the information 
requirements categories that are identified in Part 2 of this report. The columns are the 
various modeling approaches, the rows are the criteria categories and the cells are 


evaluations (no support, poor, good, very good, etc.). 


The table indicates that the ‘state of the art’ of product modeling covers assigned properties 
and design requirements very well. Design standards receive poor coverage primarily 
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because the content is not yet available in a computer sensible format. Currently, design 
standards, codes and regulations are referenced as external documents. Behavior 
representation is out-of-scope for STEP models whereas FFB/SME and PLIB support its 
representation. STEP support for task coordination is static and therefore it is rated poor. 
Task coordination is out-of-scope for FFB/SME and PLIB. Identification is “very good’ 
for each method, however integration with procurement transactions is not explicitly 


represented by any of the modeling methods shown. 


FFB/SME explicitly integrates a product and process model to automate analysis and 
evaluation tasks. PLIB explicitly supports the product selection process and could 
probably be adapted to support other engineering processes. The other models have no 


formalism for integrating product and process descriptions. 
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Table 3-1. Satisfaction of information requirements by different 
modeling methods. 


Data Properties 


Task Coordination 


The following description and analysis of each modeling method explains in detail the 
evaluations summarized by the table. 


3.1.3. Form, Function, Behavior (FFB) / Symbolic Modeling Extension 
(SME) Conceptual Model 


FFB/SME has antecedents in formal symbolic modeling [Kunz 1988], [Dym and Levitt 
1991], the design process framework of [Gero 1995], and in particular, Interpretation 


Objects developed by [Clayton, Fruchter, Krawinkler, Teicholz 1994]. Interpretation 
Objects are realized in SME. It was extended for this project. 


A model is a type of representation that simplifies organizes and abstracts the perception of 
an artifact or phenomenon. Models assist in the description, analysis and solution of 
problems concerning various phenomena and artifacts. A fundamental concept of a model 
is the distinction between an object or phenomenon, and its representation. The choice of 
representation is dependent upon what is being modeled, the purposes for which the model 
is developed, and the assumptions held by the individual(s) who create the model. This 
definition enables the representational capacity of a model to be evaluated in terms of 


business as well as technical purposes that are realized through work process. 


The formal symbolic modeling approach contends that, while model semantics vary 
according to modeling purposes, most modeled systems can be represented explicitly in 
terms of the modeled system’s structure and functional behavior [Kunz 1988]. Similar 
concepts have been elaborated and extended by others. [Gero 1995] uses the terms 
function, structure, and behavior to describe model characteristics. [Clayton, Fischer, 
Kunz, Fruchter 1995] articulates the product model in terms of the form, function and 
behavior of system elements: 

¢ Forms are the geometry and materials of the artifact; 


¢ Functions are the required and desired qualities of the artifact. Synonyms for 
functions include goals, intents, requirements, and purpose; 


e Behavior is the performance of the artifact under particular conditions. 
Modeling Process 


Through reification of FFB, symbolic models enable the explicit representation of the 
internal states of a system. [Gero 1995] elaborates a causal relationship between FFB 
elements and incorporates them into a design process framework in which the interaction of 
form and function constraints determine behavior. The comparison of predicted behaviors 
with intended functions can necessitate ‘reformulation’ of form and function characteristics 
to satisfy behavior constraints. Contrary to intuition, there is no explicit causal 
relationship between form and function. An artifact with a given form can be used for 
several, functionally independent purposes. Through the activities of designing! the 


designer reconciles form, function and behavior to provide an acceptable solution for a 


as: 


1Gero uses the word ‘designing’ to signify the process of creating an artifact and ‘design’ to signify the 
description of the designed artifact. 
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design problem. Gero maps the form, function, behavior relationships to the following 
activities of designing: 

¢ formulation; 

e synthesis; 

e analysis; 

¢ evaluation; 

¢ reformulation; 

¢ production; 

e design description. 


These activities define the steps for the application of design knowledge and reasoning to 
the definition and refinement of a product model. They represent the value added service 
provided by design and engineering professionals, yet the knowledge content of these 
activities is not fully or explicitly represented in current information models. The full value 
of the design and engineering service is not captured at each stage of the design project nor 


is it passed to the facility owner. 


The creative element of design formulation and synthesis is beyond the capability of current 
computing technology, however model based reasoning for the analysis and evaluation 
phase of designing is possible using symbolic models that explicitly represent the constraint 
relationships between object form, function and behavior [Luth, Krawinkler, Law 1991], 
[Clayton, Fischer, Kunz, Fruchter 1995]. 


Views 


The model definition provided above stresses the usefulness of a particular model for a 
given purpose or user intent. The content of a model should be parsimonious to the extent 


that it contains only the information necessary to fulfill a modeling purpose. 


In relational databases, views limit the visible fields of a relation. [Law 1992] explores 
object definition and management for topological views of structural elements based on 
underlying relations. View development for the design context and designing activities in 
an A/E/C product model is challenging due to the complexity and diversity of information 
perspectives for the various disciplines. Yet, product model views are necessary to 
provide a context for model based analysis and evaluation. 


Integration of Product Description, Process and View 


[Clayton, Fruchter, Krawinkler, Kunz, Teicholz 1993] propose a method, called 
Interpretation, for the real time assignment of views to a product model. They emphasize 


designing as a visual process in which practitioners informally draw ideas before 
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semantically interpreting them into symbols that are subject to analysis and evaluation. 
Relating this perspective to Gero’s work, interpretation further clarifies the difference 
between ‘formulation’ and ‘analysis and evaluation’. To model the work process, they 
argue for interactive interpretation as another activity of designing. [Clayton, Fischer, 
Kunz, Fruchter 1995] reifies the interpretation of design shapes (walls, doors, etc.) 
through Interpretation Objects. An Interpretation Object relates design forms with a 
functional issue (e.g., cost estimation, energy, egress and spatial requirements analysis) in 
the SME prototype. Interpretation objects then may be ‘critiqued’ according to 
interpretation specific constraints. A Critique generates predicted behaviors for a 
functional issue that is associated with a set of forms. It then evaluates the predicted 
behaviors in terms of the functional requirements and furnishes an analysis to the user. 
Each Interpretation is a view of a product model?. Clayton calls the run-time association 
of Interpretations to a CAD representation a “Virtual Product Model”. 


Analysis 


SME demonstrates dynamic annotation of CAD graphics with interpretation (view based) 
product model information. Equally important, through the integration of critique objects 
into the product model, it shows that model based analysis and evaluation, and thus 


automated engineering process, is possible for architectural design. 


The FFB modeling concepts that underlie SME are well suited to product description. 
However, the term form currently encapsulates both geometry and material. In retrospect 
this definition may be suitable for certain system level design analyses. However, for 
piping products such as control valves and process media, the geometry and material 
properties are sufficiently distinct to merit a separate classification category for each. In 
the future, it may be appropriate to designate a modeling metaphor called Form, Material, 
Function and Behavior (FMFB). 


In addition, it is clear that task coordination and administration requirements are out-of- 
scope for the SME prototype. FFB is a strong metaphor and organizing principle for 
describing the product model. SME describes work process and encapsulates engineering 
knowledge. However, a different set of intrinsic metaphors should be developed for the 


other requirements. 


2 Interestingly, the application of set operations (intersetion, union, difference) to a collection of 
Interpretations leads to insights about shared information between them. Clayton’s SME implementation 
begins to explore this through user interface tools that allow the user to perform sét operations on available 
interpretations. 
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Despite the scope limitations, the product, process integration features of SME/FFB are 
sufficiently strong to demonstrate an incremental, but significant value added service of 
information models. The control valve test case uses the FFB/SME approach and explores 


whether it is suitable for computer assisted support for control valve sizing. 
3.1.4 STEP/EXPRESS_ Models 
The EXPRESS Information Modeling Language 


STEP models are bounded by the representational limits of EXPRESS. It provides a rich 
set of features for developing an information model design, including the schema, the 
entity, the type, and the rule. It also has processes, functions and expressions. From 
these basics, it offers object inheritance, derived values and constraint management at 
STEP file compile time. Nonetheless, EXPRESS is not a programming language. It 
does not support input, output, exception handling or other common features of 
programming languages. For a thorough discussion of EXPRESS see [ISO IS 10303-11 
1994], [Schenck, Wilson 1994]. 


EXPRESS generates information models that have a fixed, apriori definition of model 
structure and entity relationships. It is not currently possible to programatically add, 
change, or modify an EXPRESS schema. (The EDM-2 system developed by [Eastman 
1995] explores several research issues relevant to dynamic conceptual data models.) In 
addition, EXPRESS does not offer a generalized method capability>. It does not yet 
support object behavior. Therefore it is not currently feasible to formalize engineering 
analysis and evaluation knowledge using EXPRESS. In addition, it would be difficult to 
implement automated design contingency or active change notification at the conceptual data 
model level*. Last, there is no formalism within STEP/EXPRESS for the conceptual 
definition of task based views. This limitation currently makes it difficult to reference a 
view of a specific component representation (other than geometric representation; solid 
model, 2D model, etc.) for a particular design or engineering purpose within in a STEP 
conformant product model. Exploration of this issue for the integration of ISO 13584, 
PLIB and STEP is an action item for the STEP architecture committee ISO/SC4/WG10. 


3 new version of EXPRESS (due for draft standard vote in Q1 1997) will support events, processes and 
states. EXPRESS models will enable the definition of a method signature. Method invocation will be 
supported through Strategic Data Access Interface (SDAI) calls to an external function library. 


4References to research in these areas include [Khedro, Genesereth, Teicholz 1993], [Petrie 1993]. 


3-8 


The current limitations of EXPRESS? constitute the fundamental criticisms of STEP as a 
technology that satisfies the conceptual data model requirements for a life cycle facility 
model that changes and evolves. 


Process Industry Application Protocols 


Despite the limitations of EXPRESS, the following discussion of AP 221 and AP 227 
shows the variation in the design of STEP models at the ARM level. The variance in 


modeling methods reflect different requirements, expectations and philosophy. 


AP 221 and AP 227 are the first efforts of the process industry to establish STEP for the 
facility life cycle. At the time of this writing, they are in the Committee Draft (CD) review 
phase. A new application protocol, AP231, that defines process information is also 
approved for development. This discussion focuses on AP221 and AP227. 


AP 221 


AP 221 describes the functional definition of plant items that are represented in a P&ID 
diagram. 


Content 


The classes of data within the scope of the AP include [ISO WD 10303-221 1995]: 

¢ the identification and classification of functional or logical items within a plant; 

e the identification and classification of physical items within a plant; 

¢ the composition and connectivity of logical and physical items; 

e the characteristics of logical and physical items; 

e the 2D and 3D schematic representation of the logical items and their connectivity. 
¢ version control data; 

¢ audit trail data; 

e data which reference external documentation; 


¢ approval status data. 
Architecture 


AP221 is based upon the Core Model adopted by the European Process Industries STEP 
Technical Liaison (EPISTLE) [SIPM ICG/2 1995]. The Core Model is a conceptual data 
model designed to provide a common underlying data representation for domain specific 
information models. The Generic Entity Framework (GEF) furnishes the conceptual basis 


SWe will see that the design of AP 221 attempts to circument some of the fimitations of the STEP 
modeling methods, but this design also introduces new nisks for standard conformance class validation. 


3-9 


of the Core Model. It consists of “four sets orthogonal subtypes” [ISO WD 10303-221 
1995] that qualify a domain specific entity. A domain object can be placed in only one 
subtype of each of the sets. The four sets are: 


¢ Subject; furnishes a conceptual definition for an entity. Top level subsets of subject 
include Material, Activity, Association, Token, Characteristic, Operation. 


¢ Instanciation; the distinction between the type of an object and an occurrence of it. The 
GEF recognizes two types of instanciation; specific and typical. 


e Life cycle; objects have different logical state conditions (actual, required, planned, 
predicted) that reflect their life cycle stage. These states may not be mutually 
exclusive. 


¢ Reality; another dimension of state. An object either exists as a thing, or is fiction 
(e.g., a designed entity). : 

Beyond these entity classification qualifiers, the underlying concepts of the Core Model 

include. 


Data driven model 


The GEF provides a set of meta-entity relationships that define object classification and the 
definition of object relations. This enables classification and the assignment of object 
characteristics to be data driven. The AP defines a baseline set of classes, objects, and 
associations in a data dictionary that users may extend or change. The data dictionary 
seeks to obviate the need for a standard object hierarchy. This approach attempts to 
resolve the fact that organizations have different component and equipment functional 
classification schemes and that it is difficult, if not impossible, to capture all the information 
requirements in the structure of one information model. The intent is to provide a data 
sharing structure for which the contents can be standardized on a project by project basis 
and enforced through business relationships. 


Object attributes (characteristics) are themselves objects. This enables their classification 
(classification by data as for any other object), and equally important it enables a 
characteristic to be shared by multiple objects. 


Separation of logical and physical entity definition accommodates change 


AP 221 separates the logical and physical definition of the object. The logical item 
provides an invariant service to the process plant. The physical item can (and does) 
change state. For example a pump (logical item) induces pressure in a system (invariant 
service), whereas the pump (physical item) can be replaced when necessary. Since all 
object carry identification and version control data, this feature provides a mechanism for 
change control. > os 
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Analysis 


The GEF permits a very general and flexible model definition by splitting object properties 
into four information axis that are related through explicit association. It mixes relational 
concepts with object oriented information modeling techniques. Association of 
characteristics to objects (rather than characteristics being intrinsic properties of objects) 
enables data normalization for characteristics and establishes the object role and semantics. 
The reification of characteristics, objects, and associations also enables the topological and 
class definition to be data driven. 


The data dictionary approach carries increased risk for conformance class validation. 
Vendors must validate AP221 compliance for the exchange of project data between systems 
and for the exchange of class libraries. The fact that the class libraries are user extensible 
makes the definition of conformance classes more challenging. The PLIB standard (see 
forward) also enables user extension to a class library. However, PLIB also offers a 
feature that assures the integrity of library entries (absolute logical identifier), and it enables 
cross references to be made between library entries with different semantics (semantic 
dictionary). These modeling tools provide a method for enabling compatibility between 
different library customizations. 


The general features of the core model overlap to some extent with the architecture and 
purpose of the STEP Integrated Resources. This overlap caused harmonization problems 


with AP 227 during development, but is being resolved during the interpretation process. 


In terms of the information requirements, it is evident that the AP221 conceptual model 
describes product properties, functional requirements but not a plant item behavioral 
representation. This fact is a result of AP scope and the modeling limitations of 
EXPRESS described above. 


The GEF circumvents the limitations of the static, a priori model definition described above 
for classic STEP. Nonetheless, like STEP it assumes that software applications provide 
data management services for a data repository rather than binding data management 
behaviors directly to the conceptual data model itself. For example, AP 221 and STEP 
models in general (through the Integrated Resources) provide schemas to indicate design 
change, design versions, and approval status for file exchange. Indicating change when a 
file is exchanged is helpful, but it is not equivalent to automated change management 
through constraint management at the conceptual data model level. [Eastman 1995] shows 
it is possible to define contingency constraints between design elements and assign 
constraint violation functions for them that monitor and control design change within the 
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product model. Given the possibility for variation in software conformance to the 
standard, it remains to be seen whether the Core Data Model can successfully support life 
cycle requirements (such as the task coordination requirements) across software 
applications and therefore between organizations. The distinction between encapsulating 
behavior and data together or separating them represents a fundamental difference between 
object oriented and relational modeling concepts. 


There is no formalization for a description of engineering process (tasks) within AP221. 
AP 227 
Content 


AP 227 describes the shape, spatial arrangement and materials of plant systems. The data 
within the scope of the AP include [ISO CD 10303-227 1995]: 

e The spatial arrangement of plant systems within the process plant; 

e Explicit representation of the 3D shape of piping systems; 


e Explicit representation of the 3D external shape of piping components and connected 
equipment of the piping system, that may include parametric, envelope, outline, and 
detailed representations of external shape; 


e The spatial arrangement of piping components and connected equipment that comprise 
the piping system; 


e The logical configuration (connectivity and sequencing) of the piping system and the 
relationship of the logical configuration to the physical realization; 


e Basic engineering data as needed for spatial layout and configuration of the piping 
system; 


e References to or designation of functional characteristics of piping components and 
connected equipment; 


e The identification, shape, location, orientation, physical connectivity, and routings of 
components of plant systems, including HVAC, structural, mechanical, electrical 
equipment and raceways, and instrumentation and controls for non-piping systems, 
reserved areas, and space occupying architectural components; 


¢ References to specifications, standards, guidelines, or regulations, for the piping 
systems, components, or connected equipment that may specify physical 
characteristics; 


e Status of plant spatial arrangement, piping components, and connected equipment; 
e Connections and connection requirements for piping components and equipment; 
e Definition of piping components sufficient for the acquisition of the components; 


e Change request, approval, notification, verification, delta tracking, and documentation 
of plant spatial arrangement, piping components, and connected equipment. 


i 
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Architecture 


AP 227 follows the classic STEP development model. It offers an a priori, fixed 
definition of object topology, definition and description. In contrast to AP 221, the 
domain independent features of AP 227 (change control, procurement specification, 
references to specification documents, etc.) are referenced directly from the STEP 
Integrated Resources. The architectural limitations of AP 227 are bounded by those of 
EXPRESS discussed previously. 


Analysis 


Because this AP is static there is always a possibility that the model definition lacks the 
objects and attributes to sufficiently satisfy usage requirements. The question must be 
answered whether an AP 227 file exchange that does not transfer 100% of the data is 
acceptable. This issue is being addressed through the definition of conformance classes 
for software vendor compliance to the standard. The definition of conformance classes 
should be less complex than for AP 221. If acceptance of the standard is hampered by the 
discovery of new information requirements, it will be critical to update the standard 
quickly. 


In terms of the information requirement categories from Part 2, the coverage of AP 227 is 
similar to that of AP221. It represents component properties but does not describe 
component behavior. The limitations for task coordination are bounded by the limits of 
EXPRESS and by the AP scope. There is no explicit description of engineering process 
that describes the process design and engineering tasks which relate to plant spatial layout. 


Functional requirements in AP 227 do appear to be described from a ‘view’ perspective, 
but the user perspective of the view is not represented explicitly. Information appears 
within different portions of the information model without a formalism for views (other 
than designed versus installed which conceptually are adopted from AP 221). Note the 
entities Functional_Object, Stream_Design_Case ffor stream data and 
Service_Operator_Case for equipment [ISO CD 10303-227 1995]. This 'view' related 
data (with respect to the notion that the information satisfies a particular set of requirements 
or perspective of the model) should be mappable to ISO013584, PLIB which has a strong 


formalism for views (see forward). 
ISO 13584, Part Libraries 
ISO 13584 Standard Parts Library (PLIB) is a conceptual model and set of implementation 


resources for information exchange between part libraries and between a part library and a 


product model. PLIB contains no description of component content. The specification 
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for the PLIB information model is domain independent. This fact differentiates it from the 
STEP APs which develop information content for an industry domain and formalize it into 
an information model. PLIB describes: 


¢ the information structure for parts and for an integrated part library that defines parts, 
part families, and their relationships; 


¢ facilities for semantically describing parts families, for cross referencing them, and for 
accessing and selecting them; 


e the minimum functional requirements for the software services that a library 
management system should provide for producers and users of part information. 

PLIB provides a standard for the integrated and interoperable compilation, access and 

selection of part information from diverse information sources. The standard assumes that 

part information suppliers (manufacturers, standard organizations, etc.) furnish PLIB 

compliant information models that a user or an information integrator compiles into a part 

library. This is an information liability and validation issue. Information owners should 


maintain responsibility for the accuracy of library contents. 


Information ISO 13584 
Library pmeema Component Family 
Models 
End-Users Information Integrators Suppliers 


A/E/C professionals Software developer; Manufacturers; 
Owners In-house MIS service; Industry Consortiums; 
WWW Virtual library; Standards .~ 
other... organizations 


Figure 3-2. PLIB Exchange Roles 


In addition to library compilation, the information integrator provides library management 
services such as integration with the user’s database management and CAD system, and 
other library management services. This role can be in-house or furnished by an external 
provider. Within the PLIB framework, control of library content is an enterprise policy 


issue, not a technology issue. 


Exchange Models 


It was noted above that PLIB supports library to library exchange as well as library to 


product model exchange. The standard identifies three types of exchange: 
Exchange by Value 


The base case. When a user selects a part from a library, the system transfers an explicit 
part representation to the product model. If the user exchanges the product model with 
another party, the exchange of the part representation is subsumed within an ISO 10303 


pase 


exchange process. 
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Exchange by Reference assuming consistent libraries 


When a user selects a part from a library, the system transfers all or a portion of the part 
representation to the product model by reference. If the user exchanges the product model 
with another party, the library of the sender and receiver must contain the same part 
information for no data loss to occur. 


Exchange by reference assuming inconsistent libraries 


Exchange by reference. However when a product model exchange occurs, the system 
transfers both the product model (ISO 10303 exchange) and the necessary library 
information (ISO 13584 exchange) without making assumptions about the content of the 


library in the receiving system. 


These exchange models are general descriptions. Despite the fact that they were devised 
prior to the advent of the World Wide Web (WWW), they remain applicable. Since the 
standard enables library to library exchange, one can imagine a user directly accessing a 
component manufacturer library, downloading component information directly into a user 


library and eventually importing a particular component description into a product model. 


However, it should be remembered that these exchange models are proposals for ISO 
13584 and ISO 10303 interoperability. There is no mechanism in place yet for assuring 
ISO 10303 compliant component representation within PLIB. Furthermore the two 
standards do not currently have an equivalent component representation schema. The 
mechanics of PLIB part instanciation in a STEP compliant product model is a current action 
item for the STEP Architecture committee, ISO/SC4/TC184/WG10. 


Architecture 


Figure 3-3 is an adaptation of the system architecture diagram provided by PLIB. Fora 
thorough description of each sub-system, see [ISO CD 13584-10 1995]. The elements of 
the standard that are most relevant to the satisfaction of the component and process 
description requirements identified in the study include sub-system 3) Dictionary and 4) 
Data + Structure + Algorithms. 
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Figure 3-3. PLIB System Architecture 
[ISO CD 13584-10] 


Data + Structure + Algorithms 


The information structure of ISO 13584, specifies three class hierarchies, General and 
Functional model classes and Views. These class hierarchies are tree structured with 
single inheritance [ISO CD 13584-42 1995]. 


General Model Classes 


General model classes specify parts through the definition of a set of properties that 
uniquely characterize them. The structure of the general model classes consists of two 
sections. The higher section “classifies technical fields and also defines the first levels of 
generic families of parts. Generic families of parts are for classification purposes. They 
are not intended to be instanciated. The lower section splits these families into generic 
sub-families to obtain simple families of parts” [ISO CD 13584-42 1995]. Simple families 
are identified by a part supplier and normally correspond to a particular product line. A 
part from a simple family may be instanciated whether or not it belongs to a supplier or is 
defined as a “generic” part. Part identification occurs through the unique naming of a part 
supplier, and the simple and generic family properties. 


PLIB recognizes that real world perspectives of the structure for part families differ, for 
example between two suppliers who sell competing products. Thus, in addition to the 
definition of a reference hierarchy for a part family based upon PLIB specified property 
characterization rules and guidelines, the standard also defines Class Valued Properties 
[ISO CD 13584-42 1995] that enable alternative family structures to be associated with a 
reference hierarchy. Thus, a product line organized according to a class hierarchy 
structure ‘X’ can be referenced in a PLIB reference hierarchy ‘Y’ as a Class Valued 
Property with a single value. This property is inherited by all the subclasses of ‘Y’. This 


mechanism allows cross reference between different part family organization structures. 
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In STEP the Integrated Resources (IR) offer the Product and Product Definition entities that 
enable an equivalent definition of a General Model class structure. However, the STEP 
IRs have not implemented the equivalent of a Class Valued Property the enables one class 
structure to reference another. In this regard, the information modeling requirements for 
part library families are significantly different than those for a product model. 


A part property may be an attribute (numeric, alphanumeric, boolean or derived values), 
another part, or in theory, an ordered list of parts. Based on these distinctions ISO 13584 
categorizes libraries into levels 1, 2, and 3 respectively. A screw, for example is a part 
whose properties are attributes only. Thus a screw can be described in a level one library. 
A control valve on the other hand, is an component that is comprised of several parts (valve 
body, trim, actuator, bonnet, etc.). If a supplier wanted to describe a control valve that 
includes an explicit representation of the constituent parts, he would need to define a level 2 
or 3 library. The choice between level 2 and 3 depends upon whether the supplier chooses 
to describe the parts as separate properties of the valve or as an ordered list. Thus Level 2 
and 3 libraries support the description of assembled parts or components as they are 
defined in this report. However, level 3 libraries pose implementation difficulties for 
relational database environments. For this reason the level 3 library is not yet officially 
supported by the standard. Thus ISO 13584 does not yet fully satisfy the aggregation 
requirement for explicit representation of the parts that comprise acomponent. Multi 


valued attributes do not pose a problem in object oriented systems. 


The standard supports a description of object behavior and thus satisfies an important 
information requirement of the study. Tables, rules or methods can provide derived 
attribute values. [ISO CDC 13584-20 1994] is an EXPRESS specification for the 
exchange of expressions that enables PLIB to support method exchange. 


For specification of entries in the semantic dictionary (see forward) part properties are 
typed according to whether they are identification attributes, context parameters or behavior 
representation attributes. These types correspond closely to the component properties and 
behaviors identified in the study. The type system identifies component attributes that are 
independent of the product model, contingent upon it, or dependent upon it to describe 
predicted component performance. Thus conceptually, the standard furnishes the 
semantics to enable product selection through interaction between the library management 
system and a product model. In the base case the interaction would be manual assignment 
of values to component variables. In a system that includes a symbolic as well as graphic 
product model representation, programmatic interaction between the.product model and a 


library system is possible for ‘intelligent’ product selection. 
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Functional Model Classes 


Functional model classes define the properties for different representation categories (e.g. 
wire frame, b-rep, etc.) for parts. “The description of a functional model class is similar to 
the description of a parts family, except that it contains only context parameters, 
representation attributes, derivation functions (if any) and methods. The methods are 
associated with the view logical names, and possibly with the view control variables, 
which allow the user to request them” [ISO CD 13584-10 1995]. A part may be 


associated with several functional model classes and thus have multiple representations. 
Views 


“The view is the structuring unit for the data produced by an integrated library for output to 
the CAD system for the purpose of representing parts” [ISO CD 13584-10 1995]. There 
are two types: general and functional views. A general view represents a part in the 
product model data, whereas a functional view is an information model for a part 
representation category in a product model. The concept of view is unique to PLIB. It is 
not incorporated explicitly into STEP. 

A functional view refers to a general view; 

corresponds to a logical view name, and possibly to view contro] variable 

srinbtersbiatbecrmitnes [ISO CD 13584-10 1995]. 
Functional view classes define the representation categories for functional model classes. 
Consider the solid model representation category (or functional model). Functional views 
for this category might include plan, section, cut-away, elevation, isometric and 
perspective. Furthermore, the representational abstraction for each functional view might 
vary depending upon the zoom level for the view ina CAD system. Such factors are 
contingent upon the purpose for the view and the information that should be available to the 
user. An equivalent analogy can be made for other representational categories such as a 
procurement and engineering management database views. The PLIB authors developed 
the functional view class concept to support component selection. Nonetheless, the 
mechanism is general and could be extended for other processes. 


STEP supports multiple representation categories (solid model, wire frame, etc.) for an 
entity, however these categories are currently limited to geometry. They do not incorporate 
the view concept for a perspective of a type of geometric representation or of a general 
definition for a task based view. 


Currently, the concept of functional view classes requires further research, development 


and implementation. Component geometry is the first representation category to require a 
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definition for functional views. However, PLIB has not yet developed an information 
model for the neutral representation of standard part geometry using EXPRESS. [Liset, 
Moen, Myklebust 1994]®. To specify CAD geometric representation for semantic objects 
requires the development of an implementation independent parametric representation 
capability. Parametrics is acurrent STEP action item. Other class hierarchies, including 
view categories to support engineering tasks, would follow after the formalization of 


geometric representation categories. 
Dictionary 


ISO 13584 part families (class definitions and attributes) are entered in a Semantic 
Dictionary [ISO CD 13584-24 1995]. The dictionary is a table in which each entry is 
characterized in terms of an absolute identifier and a descriptor. The absolute identifier 
assures that each entry has a unique semantic meaning. The dictionary supports four 
formal semantic links between entries (is_a, is_case_of, is_part_of, and is_view_of) [ISO 
CD 13584-10 1995]. This mechanism enables cross reference between entries and thus 
between different supplier part families in the library. Furthermore, the separation of the 
logical identifier describing which elements are present in a part family from their semantic 
definition provides a mechanism for changing the logical description (through product 
catalogue updates, etc.) without affecting the semantic definition. The formal semantic 
links between dictionary entries provides a basis for software services to query the library 


for part access, specification, selection, etc. 


Analysis 


PLIB is still in development. At this stage, six of nine documents that currently comprise 
the standard are in the ISO development process (see Appendix F for a document list). 
Work items to develop geometrical view exchange protocols have not begun. In concept 
the standard offers many features for the representation and exchange of parts and part 
library information. These proposed features will: 


e Enable information owners (manufacturers and standards organizations) to develop 
computer sensible, implementation independent library information models that 
represent part catalogues and part standardization schemas; 


¢ Enable end users to compile supplier library information models into an integrated, 
standardized user part library; 


6The developers of PLIB have specified an Application Programming Interface [ISO DRAFT 13584-31 
1994], based on a FORTRAN binding, that references an EXPRESS logical model for a target CAD 
system. 


3-19 


¢ Provide conceptual models to support data exchange from library to library and library 
to product model; 


¢ Distinguish between a unique definition for part semantics and multiple classification 
schemas. This enables cross referencing between supplier products (including 
international language translation) and part standards; 


e Furnish a mechanism for multiple, view based representation of parts for different 
modeling purposes; 


* Support object behavior and methods to compute the predicted behavior of candidate 
parts for selection in a design; 


e Provide semantic typing to distinguish between independent, dependent and behavior 
properties for parts. 

Conceptually, the standard can support process automation for engineering evaluation and 

analysis tasks through a library management system that furnishes programmatic interaction 


between a product model and part library to automate part selection. 


Concerning the information requirements identified in the study, PLIB provides an 
information model framework that is capable of describing component properties and 
behaviors. The framework does not attempt to explicitly represent process description. It 
depends upon part information providers to furnish the methods and functional views to 
model process (part search and selection), perhaps implicitly. Nonetheless, when a 
functional view class framework is in place and a part library is integrated with a library 
management system, the PLIB framework could satisfy the information requirement for 
integration of product and task based process description. Task coordination requirements 
and procurement transaction models are out of scope for PLIB. | 


It has been noted that PLIB is not integrated with STEP and that this topic is a current 
action item within ISO/SC4/TC184/WG10. PLIB is developed outside the traditional 
STEP architecture and implementation process. There is a proposal to reference PLIB as 
an external resource for the Integrated Resources through an interfacing schema. Since 
this mechanism would be new for STEP, it may require an extensive review of the STEP 
architecture and methods. To do this will be time consuming and a somewhat political 


process. The costs, benefits of this option need to be identified. 


3.1.5 Summary of Methods 
The review of AP information models based on EXPRESS indicate that the ‘state of the art’ 


for product models does not yet integrate a product data, behavior and engineering process 
description. PLIB may one day provide support for library management systems (non 
standard implementations) that can provide task automation services for part procurement. 


tag 
~~ 
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However, presently PLIB does not offer an integrated link for graphical representation of 
parts and product models. In addition, PLIB does not explicitly model task process. 


The existing models reviewed for this study are useful for improving product data 
exchange, but they are not intended to support the sharing of engineering knowledge and 
decision support reasoning capability. In this sense, they do not furnish an underlying IT 


capability to improve knowledge (as opposed to information) distribution, access, and use. 


The scope of FFB/SME is limited to a small portion of the information modeling problem. 
Nonetheless, it supports features that incorporate an explicit representation of component 
behavior and engineering process in an information model. These features enable the 
development of a test case that offers decision support for a task and demonstrates the 
potential for such technologies to encapsulate corporate knowledge for reuse, better 


decision making and improved business process. 


3.2 Implementation 


3.2.1 Detailed Description 


The valve sizing task is properly described as the analysis and evaluation phase for 
designing a control function of a process stream. The diagram below, adapted from [Kunz 
1996] depicts a form, function, behavior view of the valve sizing task in light of Gero’s 
design process framework and Clayton’s interpretation objects. In step 1 the user 
manually ‘interprets’ a sub-system of the P&ID diagram. Through Interpretation, a 
symbolic representation of the component model links with a product model for which it 
provides the control function. The design decision support of the component model 
consists of its ability to predict and assess the behavior of a control condition for a given 
piping sub-system and set of functional requirements defined by a process stream. Step 2 
shows the ‘feature constraints for Behavior’ and the ‘Requirement constraints for behavior’ 


relations between the relevant line and steam form and function objects and the predicted 


Reg. Constraints 


Orary: 
>| Valve Product 
| Description 


alve Sizing 
Predicted Search & Actual 
Behavior Behavior 
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valve behavior object. The predicted behavior represents the required performance 
condition, given the form and function constraints that are provided. Step 3 occurs during 
the ‘Critique’ phase. The predicted valve behaviors are computed and compared with the 
actual behavior of available valve products that are available in a component library. In 
step 4 the user assesses the products that match or exceed the requirements and selects a 


valve for the design. 


To perform this service, the model represents the valve’s thermodynamic properties, the 
thermodynamic characteristics of the piping system in which it is installed and the process 
engineering knowledge for calculating a correct valve size. To support preliminary control 
valve sizing computation and analysis, the component information model incorporates [ISA 
75.01 1991] standard sizing algorithms. 


The test case performs this task for incompressible fluids. It does not represent a 
geometric valve description or its spatial configuration within a process plant. This 
modeling work has been performed within STEP [ISO CD 10303-227 1995]. In addition, 
the model does not yet represent valve trim, bonnet and actuator materials or other 
accessories. These elements are not necessary to perform preliminary sizing. However, 
as per the information requirements identified in Part 2, it would be necessary to represent 
these items if the reasoning functionality were extended to support valve material selection, 


specification, operations, and maintenance activities. 


As mentioned above, many commercial software applications provide design decision 
support. Several programs assist users to specify control valves [Fisher 1993]. The 
difference is that the test case is model based. It reifies the valve behavior within the 
design model and captures behavioral state conditions of the valve under different 
functional load conditions. Conceptually, any project participant could query the product 
model to perform this analysis. Process and behavior information is incorporated into the 
product model and can be reused easily. Conventional software applications do not 


represent this information explicitly. 


3.2.2 Application Description 


Figure 3-5 shows the valve sizing Interpretation Inspector and the P&ID CAD 
representation. Each piping sub-system item in the list box named Jtems is associated 
with an element in the CAD drawing. When the user Inspects an item, an /tem dialogue 
box opens (not shown) in which the user assigns properties and functional requirements. 
Once the annotation is complete, the user presses the Size button to invoke the 


Interpretation Critique. The user then views the Critique results by pressing the Results 
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Figure 3-5 Test Case User Interface 


button. From the Results dialogue box, the user can select an appropriate valve for the 
product model. The implementation uses the AutoCAD R12, Sun workstation platform. 
The symbolic models are developed using the Intellicorp Kappa object oriented 
programming environment for Sun OS, UNIX. 


3.2.3 Test Case Information Model 


This section describes the test case information model structure using Conceptual 
Dependency Diagrams (CDD) that are generated from the Kappa object model. A CDD is 
itself an object model generated by an application written for Kappa. The CDD application 
extracts class objects, class object relationships, and methods from a source Kappa 
application (e.g., the test case) to show the class sub-class specialization hierarchy, the 
relations between objects that are not in the same graph, and the methods that are associated 
with each class. While less expressive than general diagramming techniques (EXPRESS- 
G, OMT, etc.), the CDD is useful because one can generate it directly from the Kappa 
development environment. CDDs do not indicate class instanciation. Figure 3-6 indicates 
how to read a CDD. Refer to Appendix D for an object model figure that shows the run 
time instances that are generated from a valve sizing Interpretation. Each run time instance 


is part of an Interpretation (explained below), and can be identified by its name suffix. 


Conceptual Dependency Diagram Legend 


ie ete Relation Attribute Name]--(ObjectRelation Value) 


Child Class 
~~~ (Method!) 


Figure 3-6. Legend for Conceptual Dependency Diagram 


Parent Class 
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The suffix name is derived from the CAD drawing file with which the Interpretation is 
associated. For the diagram in Appendix D, the suffix is <@testdwg>. Figure 3-7 
(below) shows the object named Pipe_Sys_Item (PSI). Subclasses of PSI offer logical 
representations of the plant items that are necessary to perform valve sizing for a given 
control valve placement. Child classes of the PSI include Line (pipe segment), Stream 
(process media), and Valve. When a valve sizing Interpretation is created, instances of 
the Pipe, Line, and Valve objects are generated. They link to graphical elements in the 
CAD system. The object relation attributes: PSI_Function, PSI_Form, and PSI_Behavior 
link the logical PSI objects to appropriate Form, Function, Behavior objects for each 
logical object type. The FFB objects are instanciated during the Interpretation process. 
The methods bound to the PSI objects perform object management for these relations. 


The VPPM (Virtual Process Plant Model) object 


contains the methods for creating the link between wal ac tsic desea 


the symbolic model in Kappa and the CAD IPS!_Behavior] — (Generic_FFB) 


p Z {PSI_Form] —(Generic_FFB) 
representation. Figure 3-7 also shows the Valve _ (UnsetContainsttems!) 
{Pipe_Sys_ttem 
oa. - ° : . c ' 8) (GetBehaviorOb}!) 
Critique object. An instance of this object is toes Z\SetFFBinstance) 
generated each time the user invokes an hn iauste 
w (GelFunctionObj}) 
Interpretation Critique (by clicking on the Size ~ SetContainsitems! 
P ; --}(UnsetFFBinstance!) 
button in the Interpretation Inspector). It holds the | = ‘(SetPartontem) 


[graphic] — (SMEGraphic) 


valve sizing analysis and evaluation results for a | hespector| — (KcPopupFrame) 


given set of functional conditions (see forward). ger cee eee 


Figure 3-8 (see forward) shows the Form class 


objects. Instances of Line_Form represent [7°™"™ is (ramen 
; , ; ; Aye LL Side!) 
different nominal pipe diameters, classification 3 setGraphicl 
ratings and materials. These instances are re gielee 
r(getGraphic!) 
predefined and are not generated at run-time. The ‘¢ehow) 


association of the FFB object to the PSI logical ken 


object is transparent for the user. In the case of the 


Line_Form object, it occurs when the user selects Plant Model Item (VPPM) & 
Pipe System Item Objects 


a line diameter in the Line Item Inspector. 


Soe 
~~ 
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A logical object Line can be associated with any one _(Gatviscosiy) 
1 (PV) 
eteant’ Far Z (GetSpecGravity! 
= 4S (GetPvf) 
*s (GetPhasel) 
“(SetPnasel) 
Ra) 
tine_Form ¢-(GetFp) 
\. (Get FBLineF orm) 
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Diaphram 


Line_Form instance. The methods associated with 


the Line_Form class furnish the piping geometry 


factor (Fp) when it is necessary to account for pipe 


swages. The sub classes of Valve_Form 


correspond to the different valve types that are 
distinguished by shape (geometry), not by function. 


Note that Valve Form objects provide constraints for 


Valve _Form Gate 
Ball 
=\Globs 
& (GetNomDiameter) 
3(Getrl) 
*(GetFs) 
‘(Getrap 
[FeatureOmnstraintsForBshavicrs] — {Generic_Behavior) 


Figure 3-8. Form Objects 


valve behaviors through the object relation attribute 


FeatureConstraintsForBehaviors. These object 


relations reify Gero’s assertions about the causal 


relationship between form, function, and behavior 
summarized in section 3.1.3. Much like instances of 
Line_Form, Valve_Form instances are predefined and cannot be modified by the user. 
The methods bound to the Valve_Form object are ‘Get’ functions for the following 
attributes: valve style modifier (Fd), liquid pressure recovery factor (Fl),and Laminar flow 
factor (Fs). 


Figure 3-9 lists the Function and Behavior objects that relate to the Line and Stream 


objects. Instances of the Line and Stream function classes are generated at run time 


when the user enters the functional even 
{.(PredictCv)) 
criteria for each functional case. For Ecewtey 
eats [Valve _Behavior €- Rel 
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SE) 
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Interpretation. A Behavior instance is 


generated for each functional case when 


© (UnsotFFBRelation)) 
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*(GetNamel) 


Critique. Each function object relates to boi ctscatass 


the user invokes an Interpretation 


+ (SetF FBRelation)) 


a corresponding behavior object through SnasatP siasssciasons 


the object relation attribute Figure 3-9. Function and Behavior 
Objects 


ReqConstraintsForBehavior. The 
inverse object relation attribute is DerivesFromReqConstraints. The behavior methods 


bound to Valve_Behavior are of primary interest for valve sizing. They include: 
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° Coefficient of Flow, laminar flow(Cvs!); 

° Coefficient of Flow, transition flow (Cvt!); 

¢ Coefficient of Flow, turbulent flow (CvTrb!); 

¢ Reynolds number (Re!); 

¢ Reynolds number factor (Fr!); 

¢ Predict coefficient of flow (PredictCv!); 

¢ Determine whether a valve will Cavitate (DpKc!). 


The method PredictCv! formalizes an engineering process. It is called from the 
Interpretation object method Critique! (see forward). PredictCv! encapsulates the 
engineering reasoning (logic) for valve sizing analysis by determining the proper way to 
compute the sizing algorithm based upon the functional conditions (laminar, transitional, or 
turbulent flow). 


Figure 3-10 shows the Interpretation object called 
Flow_Control_Interpretation. This object 


furnishes the method Critique! which invokes valve 
(makeDisplayNames!) 

behavior object instanciaton and sets the object relations (construct 

(name!) 

; (hide Current!) 


method, a newly instanced valve behavior object |P™-Snveltterretation entanvan 
= (showCurren' 


described previously. From within the Critique! 


invokes the PredictCv! method described previously to Hen = (SetCurrentF eature’) 
perform the valve sizing analysis. Then, the Critique! Scere 
method searches for a valve library object type (e.g., See 
ButterflyType) that matches the users choice for the : Ss iss. : 
valve style (valve form object) and the valve type = (showAllF eatures) 
Search! method is invoked. Search! compares the racine 


* manager) 
*(setissuel) 


predicted valve behaviors determined from invocation of 


PredictCv! with the actual behaviors of valve type "(deleteF eatures! 
Figure 3-10. Flow Control 
Interpretation Object 


instances that are predefined in the library. Figure 3-11 


shows the simple library representation developed 
for the test case. It shows the logical object 


\IPSI_Behavior] — (Generic_ Behavior) 


Valve Lib 
ValveLib with logical object sub classes for the [PS\_Function] — (Generic_Function) 
Library [PSI_Form] —(Generic_Form) 


various valve types. These valve types have 


instances that refer to the same FFB classes as the =-(Construct) 
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4(Search!) 


product model described previously. Run time 


generated instances of Valve_Behavior to 
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differentiated from predefined, library supplied behaviors through a naming convention. 
Predefined valve behavior instance names have the prefix <Actual>. Note that the object 
relation attributes have the same name as those utilized for the PSI objects. In a more 
robust implementation, the FFB objects and properties may be separated for the library and 
product models. For the test case, this implementation was expedient. 


Information Model Summary 


The information model for the test case reifies Form, Function, Behavior objects for each 
piping system component type and explicitly associates them to logical objects that 
represent a relevant portion of a piping circuit. Generation of the instances for Form 
objects are predefined from standard component descriptions. The user can select size or 
style options for each component type through the user interface. Function objects may be 
generated (e.g., stream functional cases) at run time. There are two types of behavior 
instance: predefined or actual behaviors that describe tested component performance, and 
predicted behaviors that are generated at run time during valve sizing analysis and 
evaluation. The valve sizing equations (ISA coefficient of flow formulas) and the 
comparison of actual to predicted behavior according to engineering analysis logic 
constitutes the ‘reasoning’ of the system. This behavioral reasoning is encapsulated within 
methods. 


The SME approach enables two degrees of product model definition flexibility. First, an 
Interpretation can be developed for any evaluation and analysis reasoning that should be 
performed for a design. The dynamic annotation of Interpretation objects to a CAD 
representation allows the user to add semantic schemas as needed. Second, the separation 
and explicit association FFB objects to a logical product model enables further flexibility in 
the information model structure. The dynamic linkage of FFB types to a logical 
representation enables a range of functional and behavioral representations to be expressed 


according to constraints that are specific to form, function, and behavior properties. 


It is understood that whether model semantics have an a priori, static definition or are 
assigned at run time, the issue of standard representation for semantics persists. Without 
agreement on the semantics of content representation, information sharing is not possible. 
Through the explicit representation of behavior and process in addition to form and 
function, SME/FFB adds two additional dimensions to the modeling challenge and thereby 
significantly increases modeling complexity. The fact that there is currently no conceptual 
classification of Interpretation (process description) or FFB objects indicates the relative 
immaturity of the approach and its current lack of generality and exténsibility. This is a 


matter for further research. 
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Nonetheless, SME demonstrates the integrated representation of object form, function, 
behavior, and task based process. The test case implementation reifies the constraint 
relationships that are formalized in design process theory and indicates that they may be 
useful concepts for the development of model based evaluation and analysis software 
services. Such concepts and services are not available yet in the standard product data 


representation initiatives. 


3.2.4 Concept Validation 


To date, validation efforts for the test case have been informal. Nonetheless, the process 
model was described and the implementation was demonstrated to representatives of an E/C 
firm who had participated in the information requirements study. The response was 
positive. The formalization of process corresponded well to how engineers work. The 
concept of placing an analysis tool on the engineer’s desktop that integrates with the design 
model was consistent with the business improvement goals for the company. After the 
demonstration, representatives from the company have indicated interest in participating 


and extending the project. 


The engineering reasoning and valve sizing output of the test case was validated by 
comparing it with the output of a commercial valve sizing program for the same input 


parameters. This test was successful. 
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Part 4. Conclusion 


The project basis of the A/E/C industry leads to enterprise organization and information 
technology (IT) support systems that are fragmented. This problem manifests through 
communication problems, errors, delays, and increased cost for project participants. The 
first requirement for correcting IT support for this business problem lies in the 
standardization of product data representation. This is the challenge of ISO STEP, and 
more recently the IAI. These initiatives provide a data structure and content foundation for 
software vendors to develop integrated applications that improve communication between 
enterprises. 


Information integration through product data standardization solves only part of the 
business problem. It is also possible to formally describe processes, the things that 
individuals and organizations do with product data to achieve project goals. The 
integration of product and process description in an executable program can lead to 
software services that offer significant benefit through task automation, increased data and 


knowledge reuse, better decision making and improved coordination. 


To understand the information content issues of modeling components for such services, 
this research has: 


* Studied the business issues of information exchange and the life-cycle information 
requirements for the components that are installed in process plant facilities; 


¢ Investigated standards development for component and product information models; 


¢ Identified engineering tasks and coordination requirements that an information model 
should support for one component type and attempted to generalize the requirements; 


e Implemented a test case that begins to explore integration of a component information 
model with a task based process model to provide decision support. 


4.1 Accomplishments 


4.1.1 Case Study Observations 


The study of business and information requirements results in a detailed process 
description of the ‘life of a valve’. In this description the major tasks associated with 
valves are highlighted across the facility life cycle. This exercise identifies several 
component information requirements that are not yet addressed by APs 221 and 227. In 
particular, it is necessary to describe the parts that comprise a component and develop a 
formal description of component behavior (predicted and observed) to satisfy the 
requirements for detailed process engineering, plant commissioning, and operations and 
maintenance activities. Such extensions would make information models useful for a 
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broader range of business purposes, and in particular, the facility owner/operator would 
benefit. 


The broad range of life cycle requirements, and the impracticality of capturing them for all 
modeling purposes also indicates the necessity for a conceptual data mode] that can support 
schema evolution. A complete a priori definition of complex engineering objects will be 


very difficult to achieve. 


The study also focuses on a description of the engineering knowledge requirements for a 
specific task, preliminary control valve sizing. This is done to understand the 
requirements for describing a task based process and the interaction between process, 
product data and behavior during the activities of designing. The exploration of these 
relationships lead to another important observation of the study. An integrated description 
of product and process can lead to conceptual information models that support task 


automation. 


Current STEP modeling efforts develop process models to gain an understanding of the 
information requirements that should be included in the ARM for an AP. However, AP 
development makes no effort to formally describe process and integrate it with the object 
models that are produced. There is no formal validation whether the information models 


actually satisfy the process requirements. 


Furthermore, the modeling tools offered by EXPRESS limit the ‘state of the art’ for STEP 
information models. They do not yet support a description of object behavior or process, 
nor do they integrate a product data, behavior and engineering process description. PLIB 
does support the description of object behavior and it may one day provide support for 
library management systems (non standard implementations) that can provide task 
automation services for part procurement. However, presently PLIB does not offer an 
integrated link for graphical representation of parts and product models. In addition, PLIB 
does not explicitly model task process. 


The existing models reviewed for this study are useful for improving product data 
exchange, but they are not intended to support the sharing of engineering knowledge and 
decision support reasoning capability. In this sense, they do not furnish an underlying IT 
capability to improve knowledge (as opposed to information) distribution, access, and use. 
While it is recognized that the scope of such an effort would be very large (and require 
more resources than are available), the current modeling efforts miss a business 


opportunity to support fundamental business process change.. 
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4.1.2 Generalization of the Information Requirements 


After investigation of the requirements for one component type, the research generalizes 
them for use in a broader context. Although the categories require validation for other 
component types, it is hoped that they are a useful starting point for component description 
purposes. Hopefully, they are valid also for describing component information that relates 
to process description for task coordination as well. 


4.1.3 Test Case Implementation 


The test case demonstrates an example of product and process description integration in 
support of task automation. It formalizes a description of the piping sub system elements 
that are necessary to perform preliminary valve sizing and, through the use of Interpretation 


and Critique objects, it formalizes the valve sizing task within the product model. 


The test case performs work in a matter of seconds that interview respondents note may 
take several hours to perform manually per contro] valve given the time required for 
information search, analysis and incorporation into project documents. Most important, it 
demonstrates the usefulness of a component evaluation and analysis software service that 
interacts directly with the design model. 


4.2 Challenges 


4.2.1 Knowledge acquisition 


First, knowledge acquisition is difficult and time consuming. It turns out that the 
engineering knowledge to understand and model control valves is technically complex and 
their specification can be as much art as science. The interview process turned up 
professionals who had spent their career studying and understanding the problems 
associated with control valve specification, usage and maintenance. In addition, control 
valve specification is not always an exact engineering problem. For functional conditions 
that involve process media in the transition phase, the sizing algorithms are inexact and 
require expert judgment given the actual design conditions. In addition, control valve 
engineering very often is dependent upon the upstream conditions of the process circuit. 
This creates a problem framework issue It is quite possible for the component specification 
issues to develop into a configuration management problem which is overly complex and 


perhaps intractable. 


4.2.2 Component Information Model Design 


Review of the information model structure provided in Appendix D shows that the 


implementation is relatively ad hoc and lacks generality for the definition of the Form, 
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Function and Behavior objects. Note that the purpose of the test case was to demonstrate 
the potential for an information model that integrates a component (properties and 
behaviors) and process description, not to define a canonical information model structure. 
Nonetheless, the object hierarchy for FFB objects jumps directly from “Generic” objects to 
sub-classes specialized directly for control valves. Without a set of common FFB 
primitives from which more complex objects can be derived, it will be impossible to share 
information between models and systems Phan, Howard 1993]. A conceptual hierarchy 
for form, function, behavior objects is a matter for further investigation and research. In 
addition, there is no conceptual hierarchy to characterize the process description that is 
reified within the Interpretation object. Doing this would require extensive work to 


classify processes and decompose them into to sharable primitives as well. 


Several information models were reviewed prior to developing the prototype. The concept 
of the pipe_system_litem object to represent the logical description of the pipe, stream, and 
valve entities was adapted from ISO AP 227. Further parallelism with other models was 
not attempted. It was decided that this would be too time consuming without direct contact 
and interaction with the persons who developed the other models. Even attribute 
assignment for the various objects was subjective. It was based upon best judgment at the 
time the implementation was developed. While the rationale for the model structure and 
properties was subjective, the goal was to be internally consistent with the definition of 


structure and assignment of attributes and behaviors. 


The ad hoc nature of the test case and the general variance of modeling methods (e.g., 
AP221 and AP227), indicates the need for the development of “good” modeling principles 


and, vitally important, a set of metrics for the evaluation of information models. 
4.2.3 Limits of FFB 


In Section 3.1.3 and 3.2.2 it was noted that the FFB paradigm could be extended. 
Applying the substance properties for the process media to a Form object was not a natural 
or intrinsic way to describe process media. The Form properties associated with the 
process media had little relation to the Form properties for the pipe and valve. Resolution 
of this issue should be performed within an effort to develop a coherent and homogenous 
set of characterization hierarchies for FFB objects. 


The FFB paradigm is clearly not applicable for the task coordination and administration 
information requirements that move beyond product description to data associated with a 
component class or supplier. 


aes 
~~ 
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4.2.4 Conceptual View Framework 


The SME work raises an important issue concerning the dynamic assignment of 
Interpretation objects to a product model. It is plausible to consider a library of 
Interpretation objects from which a user annotates the entities in a product model. 
However, predefinition of Interpretation information for the product description would 
improve the efficiency of design model generation. From the perspective of a component 
library, it would be necessary to develop a conceptual view framework to support multiple 
component representations for various design and engineering tasks. The PLIB 
conceptual model offers a compelling basis for this framework. It offers a mechanism for 
homogenous characterization of component attributes at the class level (General and 
functional classes). Also, it enables users to organize and access information according to 
domain specific practice (Semantic dictionary). Last it supports multiple representation 
(functional views) of components so that information access can be organized according to 
usage requirements. Other work that formalizes process description within the A/E/C 
industry includes [Levitt, Hayes-Roth 1989] who develop the OARPLAN construction 
planner. In addition, the computational organizational modeling literature contains 
references to research that investigates conceptual frameworks for process description 
[Malone, Crowston, Lee, Pentland 1993], [Lee, Yost, and PIF Working Group 1994]. 
This research discovered no work directly related to formalization of engineering and 


business tasks for the process industries. 


4.3 Direction for Future Research 


In the future it will be possible to offer interoperable software services for nearly any 
hardware platform over distributed networks. Design and engineering professionals will 
be able to tap information and task knowledge from a ‘virtual’ desktop comprised of 
resources available within the company and from external enterprises. They will be able to 
incorporate this formalized knowledge into project work directly and thereby leverage it for 


greater productivity. 


To build towards this vision, plans for future work include further investigation into the 
integration of product and process description for component models. To validate and 
compare the findings for control valves, a second case study will be performed to either 1) 
understand the process requirements for another task related to control valves, or 2) 
understand the information requirements for design analysis and evaluation of another 


component type. From these findings, the research will investigate a task-based view 


~~ 
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framework for a conceptual data model that improves support for product and process 


model integration. 


We also hope to understand the potential business impact of software services based on 
such models by developing a new test case that demonstrates component object transactions 
using the World Wide Web. The test case will show access, retrieval, and use of 
component information objects for design and procurement between a component supplier 
and auser. The objects that are accessed from the supplier will integrate seamlessly into 
the user’s CAD system or a project database management system. The test case will be 
implemented in Java to enable the creation of component objects that support the behavior 


and process descriptions developed in this report. 


Understanding the software management issues for interoperable, distributed objects will 
be another goal of future research. In this effort, it hoped that our work, which focuses on 
information content, representation, and process functionality, can be joined with CIFE 
work by others that investigates the network middle ware requirements for interoperation of 
legacy software applications that are developed using different languages and hardware 


platforms [Kunz, Law, Howie 1996]. 


4.4 Final Remarks 


This project was co-sponsored by the National Institute for Standards and Technology 
(Research Grant: 60NANB4D1699) and by a seed project award from the Center For 
Integrated Facilities Engineering (CIFE), Stanford University. We would like to express 
our thanks to the numerous individuals (see Appendix A) who graciously donated their 
time and shared their expertise for the interviews. We would also like to extend a special 
thanks to Dr. Kent Reed and Mark Palmer of NIST for their generous support and 


assistance. 
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Appendix A 
Companies and Individuals Involved in Research Interviews 


esc Se Contact | 


Owners 
Chevron Corp. Stan Koloboff Corporate R&D, Standards 


Du Pont Bob Pigford Vendor Manager and ex-E&I 
consultant/design engineer 
Engineering/ 


Contracting Firms 
Bechtel 


Larry Damon 
Steve Lynch 


Pepe Edlinger 
Ken Cooke 
Dale Hauglum 
Dave A. van 
Staveren 


Mgr., Engineering Technology R&D 
Mgr., Engr. & Const. Technology 
Manager, R & D 

Project engineering manager 
Manager, supplier quality 
Engineering Supervisor 


Fluor Daniel Chris Jorgensen Head of engineering systems 
Mark Murphy Process engineer 
Randy Fix Engineering Technology Development 


Brown and Root, James Klein Mgr., Engineering Systems 
Inc. Development ~ 


Valve Suppliers 
Associated Process 
Controls 


Jim Carson Director of Sales 


Rick Ash 


Fischer Rosemont Ray Michael Technical engineer/marketing 
Jerry Trout Marketing 
Bill Fitzgerald Process engineer 


Jack Coulter Engineering Manager 


Information Integrators 
Autodesk Inc. 


Technical engineer/marketing 


Dir. A/E/C and FM. 
Senior software engineer and 
Manager, data exchange group. 
Sales and Marketing 

AEC Market Group 

Product Manager, Interoperability 
Products 


Ian Howell 
Ed Clapp 


Brian Cummings 
Kiumarse Zamanian 
Richard See 


Information Jim Sutton 


Handling Services 


VP, Electronic product development 


George Thomas 
Bruce Black 
Bentley Smith 


Marketing Manager 
VP, Marketing =. 
Dir., Information Integ 


ration 


Daniel J. Burk Dir., Information Integration 

Bruce G. Norton | Dir., Info. Management Vendor and 
GSA 

Mark Strandquist | Senior Mgr., Vendor products 

Jeanne Donohue Marketing, Vendor Products 

Walt Bryant Component Engineer, Parameter 
Database Engineering 

William A. Mass _ | Product engineer 

Jay Jordan President and COO, US Operations 

Paul Kennedy Senior Director, Information 
Management 

Bernie J. Michalek | VP, Marketing, US Operations 


EDI Vendor 
Sequoia Corp. Jim Pitts Principal, Sequoia Corp. 


Other Organizations 
CIMIS Matthew Tatro Engineer/developer 
Bill Knittle Co-chair, CIMIS 
Joe Hetchman Co-Chair, CIMIS 


Appendix B 
Organizations Involved in the Development of Product 
Modeling Standards for the Process Industries 


CAESAR CAESAR Offshore is a European consortium organized to 
Offshore develop products and methodologies which will enable European 
oil and natural gas industries to use digital information effectively 
in offshore development and operation, and to redesign work 
processes and organization around new information and 
communication technologies. 


Participants in CAESAR include "Statoil, Norsk Hydro, Saga 
Petroleum, Aker Dvaerner, Det Norske Veritas, The Norwegian 
Institute of Technology (NTH), The Foundation for Scientific and 
Industrial Research at the Norwegian Institute of Technology 
(SINTEF), and The Federation of Norwegian Engineering 
Industries (TBL). 


Computer Aided Logistic and Support Initiative 


Begun initially by the Department of Defense in the 1980's, 
CALS activities have extended from the defense contracting 
industries to manufacturing industry in general as companies 
realize the improved efficiencies through data standardization. 


Construction Industry Action Group 


An action group for the Construction Industry Institute 
(CI/CIAG) 


Common Industry Material Identification Standards 


CIMIS is supported by the American Petroleum 
Institute/Petroleum Industry Data Exchange (API/PIDX), 
CII/CIAG, and the Pipes Valves and Fittings roundtable (PVF). 


For 


United Nations/Electronic Data Interchange 
Administration, Commerce and Transport. 


ISO/TC184/SC4_ = sInternational Standards Organization, Technical 


Committee 184, Sub Committee 4 


European Process Industries STEP Technical Liaison 
Executive 


The mission of EPISTLE is to “identify potential collaboration 
between parties (in Europe) involved in developing standards for 
the exchange of technical information, and to organize and deliver 
technical solutions to those problems” [SIPM ICG/2 1995]. 
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POSC & 
(POSC/CAESAR) 


Product Data eXchange Institute 


PDXI has formed from the AIChemE. PDXI developed a 
process simulation data mode] that is the basis for AP 231 under 
development. 


Process Industries Executive for achieving Business 
Advantage using Standards for data Exchange 


A new consortium made up of all the consortia and companies 
involved in the development of STEP standards in the process 
industry. PIEBASE will function as a management and 
coordination body for the other efforts. 


Process Industries STEP Consortium 


A UK based consortium of large plant owners and engineering 
contractors dedicated to the development of STEP standards. 


PlantSTEP 


A US based consortium of process plant owners and engineering 
contractors dedicated to the development of STEP standards. 


Petrotechnical Open Systems Corporation 


Based in Houston, the POSC mission is to develop standards for 
a Software Integration Platform for the oil (upstream) industry 
with a focus on subsurface information. 


Cooperative Association for the Process Industry in 
the Netherlands 


“Samenwerkingsverband Process Industrie-Nederland” (SPI- 
NL), a Dutch based consortium of large plant owners and 
engineering contractors whose charter is to promote the 
development of STEP standards. 
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Kappa Object 


Hierarchy Diagram 
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A/E/C Application Protocols 


Electrical 

°) AP2) Electromechanical design and installation 

Ship Building 

ePUAP 215 Ship Arrangements 

e AP 216 Ship Molded Forms 

eM AP 217 Ship Piping 

e AP218 Ship Structures 

e AP 226 Ship Mechanical Systems 
Process Plant 

eI AP221 Functional Data and its Representation 

e = AP227 Plant Spatial Configuration 

e AP231 Process Engineering Data: Process Design and Process Specification 

of Major Equipment 

A/E/C 

GaN Pes) Structural Building Elements using explicit shape representation 
° AP 228 Bldg. Services HVAC : 

e AP 230 Bldg. Structural Frame: Steelwork 
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Appendix F 
ISO 13584 PLIB Documents (Parts) 


The following documents are in development process or are proposed within the PLIB 
initiative: 

Part 1 Overview and fundamental principles; 

Part 10 Conceptual model of parts library; 

Part 20 General resources; 

Part 24 Logical model of supplier library; 

Part 26 Supplier identification; 

Part 31 Programming interface; 

Part 42 Methodology for structuring part families; 

Part 101 Geometrical view exchange protocol by parametric program; 

Part 102 Geometrical view exchange protocol by ISO 10303 conforming specification. 
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[Chevron corp. 1993] 
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[Clayton, Kunz, Fischer, 
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